__defineGetter__ returns

Mark S. Miller erights at google.com
Tue May 7 10:24:43 PDT 2013


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/d0bfc2e0/attachment.html>


More information about the es-discuss mailing list