__defineGetter__ returns
On May 7, 2013 3:49 AM, "David Bruant" <bruant.d at gmail.com> wrote:
The latest rumors [1] suggest that
__defineGetter__will be in IE11.
Of course to benefit platform compatibility, but that doesn't mean ES6 (or ES.any) will standardize an obsolete feature alongside its superior replacement. ;)
On Tue, May 7, 2013 at 10:13 AM, Rick Waldron <waldron.rick at gmail.com>wrote:
On May 7, 2013 3:49 AM, "David Bruant" <bruant.d at gmail.com> wrote:
The latest rumors [1] suggest that
__defineGetter__will be in IE11.Of course to benefit platform compatibility, but that doesn't mean ES6 (or ES.any) will standardize an obsolete feature alongside its superior replacement. ;)
So there's no need to standardize __proto__ then, eh? ;)
</troll>
Much as I hate to say this, but if all major JS platforms support some harmless feature, cross-browser web content will come to depend on that feature. In that case, we are better off doing the work to codify an agreed common behavior for that feature, rather than have all implementors guess separately how to best be compatible with what other implementors are guessing. Remember block nested functions as a cautionary tale.
I hope we keep __defineGetter__ etc out of the cross browser web. I had
hoped we would keep __proto__ out to no avail. If __defineGetter__ etc
becomes part of the cross-browser de facto platform, TC39 should make it de
jure.
Fortunately, these are easy to shim on any ES5 platform of course. SES already does so code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/startSES.js#329. If we do codify these, we should probably follow the logic of this trivial shim.
From: Mark S. Miller [erights at google.com]
Much as I hate to say this, but if all major JS platforms support some harmless feature, cross-browser web content will come to depend on that feature. In that case, we are better off doing the work to codify an agreed common behavior for that feature, rather than have all implementors guess separately how to best be compatible with what other implementors are guessing. Remember block nested functions as a cautionary tale.
While I (sadly) agree with the sentiment, I wonder why this logic hasn't been applied to String.prototype.blink() and friends? ;)
Sigh. Probably scarcity of time and an insufficiently strong stomach rather than any real principle. FWIW, searching for "ES5 Appendix B" and "Harmless whatwg" at < code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/whitelist.js>
gives 6 and 13 candidates respectively. It is also illuminating to look at the other commented entries on this whitelist.
On 5/7/2013 8:11 AM, Domenic Denicola wrote:
While I (sadly) agree with the sentiment, I wonder why this logic hasn't been applied to
String.prototype.blink()and friends? ;)
These are already in the ES6 spec in fact, under Annex B (normative optional). This is where I presume the accessor dunders would go, and where dunder proto lived for a short while before it was upgraded to required.
On Tue, May 7, 2013 at 10:21 AM, Dean Landolt <dean at deanlandolt.com> wrote:
So there's no need to standardize
__proto__then, eh? ;)</troll>
Perhaps you should actually read the existing discussion and meeting
resolutions? __define|lookup(Getter|Setter)__ have already been
standardized in the form of the superior Object.definePropert(y|ies) APIs.
When the object meta APIs were specified, there was little support for the
dunder APIs, which made it easier to kill them. Since then, __proto__
implementation has spread, which means it's not easy to kill?which is why
it's being standardized. Note that TC39 isn't specifying two different
mechanisms either, ie. no setPrototypeOf.
Good. Appendix B (normative optional) is a fine place for these. I see no reason to promote them further.
On Tue, May 7, 2013 at 11:59 AM, Rick Waldron <waldron.rick at gmail.com>wrote:
On Tue, May 7, 2013 at 10:21 AM, Dean Landolt <dean at deanlandolt.com>wrote:
On Tue, May 7, 2013 at 10:13 AM, Rick Waldron <waldron.rick at gmail.com>wrote:
On May 7, 2013 3:49 AM, "David Bruant" <bruant.d at gmail.com> wrote:
Hi,
The latest rumors [1] suggest that defineGetter will be in IE11.
Of course to benefit platform compatibility, but that doesn't mean ES6 (or ES.any) will standardize an obsolete feature alongside its superior replacement. ;)
So there's no need to standardize proto then, eh? ;)
</troll>
Perhaps you should actually read the existing discussion and meeting resolutions?
I read them religiously, along with es-discuss, and because of this I was just noting the parallel in reasoning. But I was mostly joking -- note the </troll> tag! :D
define|lookup(Getter|Setter) have already been standardized in the form of the superior Object.definePropert(y|ies) APIs. When the object meta APIs were specified, there was little support for the dunder APIs, which made it easier to kill them. Since then, proto implementation has spread, which means it's not easy to kill—which is why it's being standardized. Note that TC39 isn't specifying two different mechanisms either, ie. no setPrototypeOf.
TC39 already specifies the other dunders in Annex B. That's where I think proto belongs. See Mark's recent comment about setPrototypeOf in recent posting -- no objection to setPrototypeOf is a pleasant surprise!
On 5/7/2013 9:09 AM, Dean Landolt wrote:
TC39 already specifies the other dunders in Annex B.
Not currently. With IE11 adding them, though, it would make sense to add them to Annex B.
Are they not in the es6 draft yet? I was going by what you'd said a half hour ago:
These are already in the ES6 spec in fact, under Annex B (normative optional).
Regardless, this seems like the perfect place for all of the duners, IMHO.
On 5/7/2013 9:16 AM, Dean Landolt wrote:
Are they not in the es6 draft yet? I was going by what you'd said a half hour ago:
These are already in the ES6 spec in fact, under Annex B (normative optional).Regardless, this seems like the perfect place for all of the duners, IMHO.
Oh apologies for not being clear. I meant the likes of
String.prototype.blink and friends are in Annex B.
Oh. Sorry for the noise.
Do you believe acting passively will keep bringing any good to the language specification?
A precedent, title of one of my posts about proto, is exactly what you have here.
"Since every browser has it, no matter how bad or good it is, let's us put that there too and it will be standard"
This seems legit to me, specially from IE that does not want to be left a part anyhow.
IE ruled out few standards in the DOM world (thankfully less in the ES one).
Same all "other" browsers implemented non standard innerHTML, IE adopted some other non-spec'd thing.
Same Chrome implemented an even falsy document.all, IE can decide that {}.defineGetter is not undefined anymore.
Not only it's used, but the new "isNotIE()" feature detection of these days is:
if ({}.defineGetter) { // not IE, not at all }
same if(document.all) was used for the inverted behavior in the past.
Same WebKit decided that innerText was fine, IE can chose anythingHere is fine too and this is OK, we should not point/complain because this is what every other engine/browser has always done.
Is just a matter of context, either DOM or ES, those once alternative browsers adopted IE non standards approach to avoid being left behind and now it's vice-versa.
I believe the elephant in the room is the adoption of experimental and non standard features, documented properly in the MDN so that everyone can learn with examples how to use them.
Instead of writing a deprecated in the MDN page, I would rather expect that every execution of a piece of code that uses these features logs in the console a warning that a deprecated thing is being used.
This is valid for every build step of any programming language, JS decided that early adoption or usage of deprecated things is fine ... trapping the future behind early and old mistakes or not fully defined behaviors (again, proto and all its partial implementations is a clear example)
I would rathe expect that this logging is noticed by developers and that not a single minute is wasted behind improving performance of that technique, I would rather see ever-green browsers reacting fast instead of supporting such deprecated, non-standard, thing, for years!
Sadly, what I see is that instead of filtering, TC39 "ignores" these things that come out of developers necessities and become standards, or decide to standardize the mess "passively", as long as all browser agreed that mess is needed.
Mark said: "all major JS platforms support some harmless feature, cross-browser web content will come to depend on that feature"
if proto is harmless, and deprecated methods such defineGetter are still there, I wonder what you consider harmfull to implement.
Object.prototype.toSource() ? something I've polyfilled for IE5 ages ago, never made it and not because harmfull, simply because pointless due inability to bring the scope around once re-evaluated.
The potentially-laser-foot-gun proto already landed, and there's nothing else that powerful that could have made it so my question is: shouldn't TC39 be a stopper for these kind of problems instead of blindly embrace whatever comes through?
I'd really like to understand what is the real TC39 role 'cause lately I am having hard time understanding this every time IE embraces some early mistake nobody cared 'till the day before if it was "all-but-IE"
Best
On Tue, May 7, 2013 at 10:15 AM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:
Mark said: "all major JS platforms support some harmless feature, cross-browser web content will come to depend on that feature"
if
__proto__is harmless, and deprecated methods such__defineGetter__are still there, I wonder what you consider harmfull to implement.
__proto__ wasn't harmless, but its harm was survivable. That's why it took
so long for the Cajadores and I to come around to the position that we
don't need to remove it from SES. We would have been better off without it,
but that's not a realistic choice.
__defineGetter__ and blink are harmless because they only do that which can
be done by other means.
RegExp.leftContext is harmful, especially when undeletable, because it
creates a global communications channel. Because it is undeletable, initSES
has to do bizarre things to remove it from SES.
You did not answer my question Mark: what is the role of TC39, embrace
"whatever non-standard crossbrowser thing" or filter ideas proposing better
alternatives/solutions when necessary in order to have a solid foundation
instead of having Object.defineProperty({get}) AND __defineGetter__ from
the past?
This is a concern of mine, and I'd like to hear a clear statement about this, thanks.
Le 07/05/2013 18:30, Andrea Giammarchi a ?crit :
You did not answer my question Mark: what is the role of TC39, embrace "whatever non-standard crossbrowser thing" or filter ideas proposing better alternatives/solutions when necessary in order to have a solid foundation instead of having
Object.defineProperty({get})AND__defineGetter__from the past?This is a concern of mine, and I'd like to hear a clear statement about this, thanks.
I'm not Mark and not part of TC39, but I'll give it a try. I believe TC39 position is in between your 2 propositions. Aiming at improving on a solid basis while still codefying de facto standards when necessary (that is when it's in some implementations and other implementors are pushed by content to implement it).
I don't get why you're being so hard on TC39. The WHATWG has been doing exactly that for years now; looking at what several browsers implement and is used in content and codifying it. Beyond the hype, large parts of HTML5 are de facto standards.
I am Mark and speak only for my fraction of TC39 ;). But I am happy with your summary. Thanks.
The latest rumors suggest that
__defineGetter__will be in IE11.