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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
