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 <slightly...@google.com>wrote: > Hey Andrea, > > Response inline. > > > On Fri, Apr 12, 2013 at 9:01 AM, Andrea Giammarchi < > andrea.giammar...@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@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
