__defineGetter__ returns

Andrea Giammarchi andrea.giammarchi at gmail.com
Tue May 7 10:15:04 PDT 2013

Do you believe acting passively will keep bringing any good to the language

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

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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130507/13a31e36/attachment-0001.html>

More information about the es-discuss mailing list