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 <erig...@google.com> wrote:
>
>
>
> On Tue, May 7, 2013 at 10:15 AM, Andrea Giammarchi <
> andrea.giammar...@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 <d...@deanlandolt.com>wrote:
>>
>>> Oh. Sorry for the noise.
>>>
>>>
>>> On Tue, May 7, 2013 at 12:18 PM, Brandon Benvie <bben...@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@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> Cheers,
> --MarkM
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
