Changing [[Prototype]]

David Bruant bruant.d at
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 ...
"you can define getters and setters using the ECMAScript5 syntax." and 
then shows an example with __define{G|S}etter__ *ahem*

=> 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.".

=> 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 :-)

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 -_-#


More information about the es-discuss mailing list