A Precedent

Andrea Giammarchi andrea.giammarchi at gmail.com
Fri Apr 12 09:09:20 PDT 2013


Alex, I wrote that with best intents. I have the incredible ability to
transform any thread in a flame so for this mailing list sake is better, as
I've written already, to be as far away as possible (I keep watching
threads though).

I'll try to quickly answer:

@gaz, yes, dictionaries and lookup tables are problematic in current mobile
webkit browsers.
__proto__ has the ability to change a `null` object.

@Alex

In current Chrome __proto__ is configurable and can be deleted. What's
missing is the ability to recycle the setter later on (the getter ain't
needed, there's Object.getProottypeOf() to do that)
Once we have that, this woul dbe possible:
https://gist.github.com/WebReflection/5247136

AFAIK, Chromium might solve this soon so no need to fork it?
http://code.google.com/p/v8/source/detail?r=14139

I understand early adopters and the fact is unfortunately in too many
browsers now as de-facto mess due all problems described before but I don't
understand the answer of TC39

__defineGetter__
__defineSetter__
__lookupGetter__
__lookupSetter__

have been used and adopted by all browsers but IE for years and the
**right** answer from TC39 has been deprecating these and proposing

Object.defineProperty(get/set)
and
Object.getOwnPropertyDescriptor()

It is still not too late to propose Object.setPrototypeOf(target,
proto):target and keep the __proto__ status deprecated 'cause I cannot
believe many of us are waiting for Object.prototype.__proto__ to be
removable so that the problem will be solved at the root.

The Mobile Zepto argument is really weak too. In the whole Zepto library,
and I believe in jQuery too, __proto__ is present in two tiny chinks of
code.
https://github.com/WebReflection/zepto/commit/66d84a05f8460f00dcf62cb610c0f12f606eff03

I've proposed already the push for that change but it comes again to
chickes or eggs:

"we would change if Object.setPrototypeOf() was specd, there's __proto__ se
we are good like this"

Performance is not an issue and the ability to change a property name or a
single piece of code makes a library a good one because refactoring is
really easy to do if the code is well organized and compact as most of the
libraries are out there.

Being also __proto__ soem dark magic nobody expect from a user input but
always managed internally, there won't be logic side effect too if not the
desire one: there are no situations where an object can be mutated by
accident.

The Ship Hasn't Sailed Yet ... ES6 is still a draft, and if that means
anything, it means it can be changed.

Object.mixin() is there too completely minimal and identical to a status
Object.setPrototypeOf(target, proto):target could be.

ES6 should spec that every property in the Object.prototype should be
configurable and propose better mechanism than one that could make
interoperability even more problematic in case node.js decides to do not
expose __proto__ and the web keep relying in a broken already deprecated
thing that will stay as it is for long time due not so new, and not so old,
Android devices, Nokia, etc.

All the best




On Fri, Apr 12, 2013 at 2:54 AM, Alex Russell <slightlyoff at google.com>wrote:

> Hey Andrea,
>
> Response inline.
>
>
> On Fri, Apr 12, 2013 at 9:01 AM, Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
>
>> "a principle or rule established in a previous case":
>> http://en.wikipedia.org/wiki/Precedent
>>
>> I should not be here and I will not answer, just my last attempt trying
>> to make a point.
>>
>
> Lobbing messages onto lists without any intent to follow up seems to me
> like it puts this out of the realm of good-faith efforts to fix something
> you think is broken.
>
>
>> Please consider the main developer behind node.js agrees this property
>> should never land in JS as it's a minefield game specially when security
>> and server side stuff is involved.
>>
>
> Assuming "this property" is __proto__, that ship sailed in V8 a long ago
> and there's zero chance of it ever being removed. It they want to remove
> it, they can simply fork V8 or ask for a build flag for it.
>
>
>> Current status:
>> https://gist.github.com/WebReflection/5370050
>>
>> // all IE < 10 browsers
>>
>> *if* (*!*('__proto__' *in* {})) {
>>
>>   console.log('you gonna have hard time');
>>
>> }
>>
>> // all Mobile WebKit browsers
>>
>> *if* ('__proto__' *in* Object.create(*null*)) {
>>
>>   console.log('you gonna have hard time');
>>
>> }
>>
>> // all not so updated Chrome browsers plus many mobile  browsers
>>
>> *if* (*!*Object.getOwnPropertyDescriptor(Object.prototype, '__proto__').configurable)
>> {
>>
>>   console.log('you gonna have hard time');
>>
>> }
>>
>> // all updated Chrome browsers plus current node.js
>>
>> *if* (*!*Object.getOwnPropertyDescriptor(Object.prototype, '__proto__').set)
>> {
>>
>>   console.log('you gonna have hard time');
>>
>> }
>>
>> now ask yourself how good is for the web to promote early adoption of
>> broken ideas so that the whole future of the language will get screwed.
>>
>
> Early adoption is for early adopters; that is to say, people willing to
> take risks knowing they might not pay off. Standardizing things is a way to
> remove risks so a larger population can benefit. That there is impl
> ambiguity is often *desireable* pre-standardization to ensure that only the
> early-adopters bite off features which might otherwise look enticing.
>
>
>> I think it's called **Butterfly Effect**, and once again this is the best
>> time ever to officially drop that property instead of promoting it!
>>
>
> Again, the ship sailed.
>
>
>>  P.S. all the community needed/wanted, wasn't a shame like that property
>> in the `Object.prototype` but a way to subclass or swap class to native,
>> untouchable, instances/constructors such NodeList and all non ArrayLike
>> objects: **nothing else**, really!
>>
>> `Object.setPrototypeOf(obj, proto):obj` is a way better answer for next JS
>>
>> _______________________________________________
>> 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/20130412/a4a24b5c/attachment-0001.html>


More information about the es-discuss mailing list