github at esdiscuss.org (2013-07-12T02:27:21.757Z)
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.
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. On Tue, May 7, 2013 at 10:24 AM, Mark S. Miller <erights at google.com> wrote: > > > > On Tue, May 7, 2013 at 10:15 AM, Andrea Giammarchi < > andrea.giammarchi at gmail.com> wrote: > >> 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. >> > > __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. > > > > >> >> 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 Regards >> >> >> >> >> On Tue, May 7, 2013 at 9:20 AM, Dean Landolt <dean at deanlandolt.com>wrote: >> >>> Oh. Sorry for the noise. >>> >>> >>> On Tue, May 7, 2013 at 12:18 PM, Brandon Benvie <bbenvie at mozilla.com>wrote: >>> >>>> 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. >>>> >>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> es-discuss at mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > > -- > Cheers, > --MarkM > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130507/1eb6e110/attachment.html>