Changing [[Prototype]]

David Bruant bruant.d at gmail.com
Fri Dec 28 02:51:27 PST 2012


Le 28/12/2012 11:20, Brendan Eich a écrit :
> David Bruant wrote:
>> What about a specific section of the spec called "de facto 
>> standards"? It would indicate that it's part of the standard, but is 
>> a scar from history rather than a legit feature.
>> An intro would explain what this is all about.
>> It would be an interesting middleground between normal spec features 
>> (which people take for the Holy Graal) and appendices (which people 
>> will skip).
>> __{define|lookup}{G|S}etter__ would fit well in this section.
> Those never made it into IE. Why include them? There's a bright line 
> drawn by interop.
I've seen Node.js code with it. Closed source so far. I don't think 
it'll be hard to find open source.
... googling ...
* 
http://blog.james-carr.org/2010/07/19/defining-getters-and-setters-in-nodejs/
"you can define getters and setters using the ECMAScript5 syntax." and 
then shows an example with __define{G|S}etter__ *ahem*

* http://nodemanual.org/0.6.9/nodejs_dev_guide/ECMA5_in_nodejs.html
=> Page titled "Using ECMA5 in Node.js"
__define{G|S}etter__ Documented, but described as "This functions is a 
Mozilla extension and is not in ECMAScript 5.".

* http://fr.slideshare.net/the_undefined/nodejs-a-quick-tour
=> Slide 15 titled "ECMAScript 5" but shows an example with __defineGetter__

Oh boy! And these are just 3 of the 4 first results I see when searching 
"nodejs __definegetter__"
Not only people do use it, but they recommand it and think it's part of ES5!


Searching in node_modules of a recent project, I see a couple of modules 
using __defineGetter__ (I count own usages, not usage in their 
submodules): express, connect, formidable, nconf, pg, winston... Half of 
the modules I use freaking use it!

Special note for chai in which I have seen the "defineGetter" string, 
but because they removed it from their source :-) 
https://github.com/chaijs/chai/blob/master/History.md#012--2011-12-18

Apparently, __define{G|S}etter__ really is a thing in Node.js. I really 
didn't have to dig deep...

>>> Then implementations can still choose not to implement them when 
>>> they can afford it, e.g. when JS is introduced into a new space 
>>> where no such legacy exists.
>> A new web browser will need these legacy features, but I agree with 
>> non-browser implementation.
>>
>
> And as we discussed in accepting __proto__ as normative not-optional:
>
> * Code gets ported, it is unlikely a new embedding will avoid 
> __proto__ if it becomes popular (Node.js is an example of how 
> __proto__ spread).
Add __define{G|S}etter__ to the list I guess -_-#

David


More information about the es-discuss mailing list