[].push wrt properties along the [[Prototype]] chain
Consider: Object.defineProperty(Object.prototype, "0", { value: 17, writable: false, configurable: false }); [].push(42); Per ES5, I think this is supposed to throw a TypeError. The push should be setting property "0" with Throw = true, which means that when [[CanPut]] fails, a TypeError gets thrown. No engine I can test does this, I suspect because everyone's mis-implemented an optimization. On IRC it was pointed out that http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake is supposed to fix this: you should be able to shadow a non-writable property on a prototype. Or something. But there's contention there about this not actually being a mistake. (I think that contention's probably right, for what it's worth, but I digress.) But suppose it isn't, for the moment. What then of this: Object.defineProperty(Object.prototype, 0, { set: function() { throw "FAIL"; } }); [].push(42) I think this should throw, again because it's *setting* property "0". But again, no engine I can test actually throws for this. My gut says this is a case where every engine attempted to optimize, and optimized wrongly such that incorrect semantics resulted. The question is, since no engine's following the spec, whether the spec should change, the engines should change, or what. Given that indexed properties on Array.prototype and Object.prototype are not something anyone sane does, I tend to think changing it to [[DefineOwnProperty]] would be good. But maybe the spec really should win, and everyone should change. I dunno. Please sort this out! :-) Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Are frozen Objects faster ?
not sure I follow here ... I did ask if Object.freeze was faster and why, if not, 'cause faster is what I would expect after a probably slower operation as freeze could be. Aymeric yes, that was unfortunate, also I don't understand all these different behaviors but point is, I think you can extend in Chrome, you cannot in Firefox and no idea why this choice (bu tI understand the implementation of static, fixed, type/shape) So, it looks like is planned, but nobody knows when? Well, that's better than nothing :-) On Fri, Feb 15, 2013 at 4:09 AM, Alex Russell wrote: > On Thursday, February 14, 2013, Andreas Rossberg wrote: > >> On 14 February 2013 19:26, Herby Vojčík wrote: >> > I meant "de facto". People wanting to remove property bar from foo do >> not >> > write `delete foo.bar` anymore; they (at least some significant subset) >> have >> > learned to write `foo.bar = null;` or `foo.bar = undefined;`. The >> reason is >> > perf - `delete` deoptimized hidden classes. >> >> And with ES6, those people will hopefully realise that for those >> cases, using a Map is a cleaner alternative anyway. >> > > I think it's worth noting here that *of course* older features have seen > heavier optimization. I honestly expect that the Map type will start much > slower than it will eventually end up being, perhaps not in V8, but > elsewhere. But slow and available often beats unavailable and/or > non-standard. It's a complicated story to tell end-users, but anything else > is misleading. > > One hopes that any new feature we that gets wide implementation and is not > explicitly performance oriented pays for itself on a semantic basis. Such > features find their natural users prior to the optimization foot race > kicking off, and there's nothing bad about any of that. The ideal world > (that freeze() is now a poster child for) looks roughly like: > > // Standard written, implementations arrive (not in that order) > // ...time passes... > Hooray! New features! > > // ...time passes... > // Users realize optimization is uneven > Boo! They're slow! // Said without any sense of JS perf history > > // ...time passes... > // Features optimized > Yay! They're fast! > > ___ > 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
Re: Are frozen Objects faster ?
Typed Arrays are not frozen on FF, they are not extensible, only new typed_array(nothing) is frozen (just bad luck for your example :-) ). Reading this thread, it seems that I am not using good practices, because I am using quite often the object literal indexed with numbers (var a={};a[1]=something), and I am using delete to remove the values (the object litteral becomes a kind of array with holes), and I really expect delete to remove the property, not to assign it to null. I find it convenient (despite of the fact that properties enumeration order in that case is let to the appreciation of the js engine and can change depending on what you are doing), is this not correct/impacting a lot performances? One day maybe there could be an annex in ES specs about good practices and performances, or does it exist somewhere? Regards, Le 14/02/2013 21:50, Andrea Giammarchi a écrit : I wodner how come Firefox behaves like that then but I don't have tests to compare any difference between these two. I will write some, thanks On Thu, Feb 14, 2013 at 12:48 PM, Andreas Rossberg mailto:rossb...@google.com>> wrote: On 14 February 2013 21:36, Andrea Giammarchi mailto:andrea.giammar...@gmail.com>> wrote: > "Binary Arrays" are indeed frozen objects, at least in Firefox, and ultra > fast: > Object.isFrozen(new Float32Array()) // true in Firefox > > Since these are ultra fast in Chrome too but not frozen, I believe there is > already a way to speed up typed stuff (didn't check how it's done though) so > I wonder how come Object.freeze() is not taking similar approach "typizing" > behind the scene the object improving all static properties getters > (probably dropping those getters where possible unless defined as such) Frozenness is largely irrelevant for typed arrays, since all array accesses are defined by a magic nameless getter/setter pair per the WebIDL spec. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- jCore Email : avi...@jcore.fr iAnonym : http://www.ianonym.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A case for removing the seal/freeze/isSealed/isFrozen traps
On 15 February 2013 14:29, Brandon Benvie wrote: > I definitely agree that something like "preventAccidentalExtensions" > (disallows new properties through [[Put]] but not [[DefineOwnProperty]]) has > more common uses cases than preventExtensions, and for the precise reasons > that David said. The security is against bugs usually, not attackers. > PreventExtensions is a clumsy tool for managing capabilities because it > leaves no room for giving *some* code permission while preventing other code, > which is exactly what we want when the clueful *me* of now is writing code to > manage the clueless *I* of the future. If you need private extensibility, just complement preventExtensions with installing a private map or expando object. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A case for removing the seal/freeze/isSealed/isFrozen traps
On Fri, Feb 15, 2013 at 9:24 AM, Erik Arvidsson wrote: > ... and security sensitive code could just ban/alter the reflection > methods. > On Feb 15, 2013 8:29 AM, "Brandon Benvie" wrote: > >> I definitely agree that something like "preventAccidentalExtensions" >> (disallows new properties through [[Put]] but not [[DefineOwnProperty]]) >> has more common uses cases than preventExtensions, and for the precise >> reasons that David said. The security is against bugs usually, not >> attackers. PreventExtensions is a clumsy tool for managing capabilities >> because it leaves no room for giving *some* code permission while >> preventing other code, which is exactly what we want when the clueful *me* >> of now is writing code to manage the clueless *I* of the future. >> > I think this would fit a really common use case, but I would say that the current attempted way to solve this problem is private names. Last I checked, private names (or the weak map variant) would not be frozen after an Object.freeze, but only trusted parties (like methods,getters/setters, and potentially those with the shared name) could modify it. The pattern I would like to see optimized for using Object.freeze is the functional approach. I think the tools are there. Object.freeze makes immutable objects, and using Object.create to use frozen objects as prototypes, and store just the differences in the child object could potentially be an elegant way of doing persistent data structures. I haven't really tested the performance of it now, but I wonder how optimized it could get. The prototype chains could get very deep, but seeing as they would all be frozen all the way up, I wonder if it could be made more efficient. - Russ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A case for removing the seal/freeze/isSealed/isFrozen traps
... and security sensitive code could just ban/alter the reflection methods. On Feb 15, 2013 8:29 AM, "Brandon Benvie" wrote: > I definitely agree that something like "preventAccidentalExtensions" > (disallows new properties through [[Put]] but not [[DefineOwnProperty]]) > has more common uses cases than preventExtensions, and for the precise > reasons that David said. The security is against bugs usually, not > attackers. PreventExtensions is a clumsy tool for managing capabilities > because it leaves no room for giving *some* code permission while > preventing other code, which is exactly what we want when the clueful *me* > of now is writing code to manage the clueless *I* of the future. > > On Feb 15, 2013, at 6:31 AM, medikoo > wrote: > > > David, that's great clarification, and indeed it looks a bit different > from > > that perspective. > > > > Still the only use case I see for freezing/sealing whole object (the way > it > > works now) is when we expose some constant dictionary object on which > each > > property counts, and that's very rare use case. > > I don't see much good in disallowing extensions to prototypes we expose. > > it's not JS way. We can prevent accidental modifications of *existing* > API's > > but disallowing custom extensions is too restrictive and not friendly in > my > > opinion. > > > > > > > > > > -- > > View this message in context: > http://mozilla.6506.n7.nabble.com/A-case-for-removing-the-seal-freeze-isSealed-isFrozen-traps-tp272443p272674.html > > Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at > Nabble.com. > > ___ > > 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 > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A case for removing the seal/freeze/isSealed/isFrozen traps
I definitely agree that something like "preventAccidentalExtensions" (disallows new properties through [[Put]] but not [[DefineOwnProperty]]) has more common uses cases than preventExtensions, and for the precise reasons that David said. The security is against bugs usually, not attackers. PreventExtensions is a clumsy tool for managing capabilities because it leaves no room for giving *some* code permission while preventing other code, which is exactly what we want when the clueful *me* of now is writing code to manage the clueless *I* of the future. On Feb 15, 2013, at 6:31 AM, medikoo wrote: > David, that's great clarification, and indeed it looks a bit different from > that perspective. > > Still the only use case I see for freezing/sealing whole object (the way it > works now) is when we expose some constant dictionary object on which each > property counts, and that's very rare use case. > I don't see much good in disallowing extensions to prototypes we expose. > it's not JS way. We can prevent accidental modifications of *existing* API's > but disallowing custom extensions is too restrictive and not friendly in my > opinion. > > > > > -- > View this message in context: > http://mozilla.6506.n7.nabble.com/A-case-for-removing-the-seal-freeze-isSealed-isFrozen-traps-tp272443p272674.html > Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at > Nabble.com. > ___ > 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
Re: Are frozen Objects faster ?
On Thursday, February 14, 2013, Andreas Rossberg wrote: > On 14 February 2013 19:26, Herby Vojčík > > wrote: > > I meant "de facto". People wanting to remove property bar from foo do not > > write `delete foo.bar` anymore; they (at least some significant subset) > have > > learned to write `foo.bar = null;` or `foo.bar = undefined;`. The reason > is > > perf - `delete` deoptimized hidden classes. > > And with ES6, those people will hopefully realise that for those > cases, using a Map is a cleaner alternative anyway. > I think it's worth noting here that *of course* older features have seen heavier optimization. I honestly expect that the Map type will start much slower than it will eventually end up being, perhaps not in V8, but elsewhere. But slow and available often beats unavailable and/or non-standard. It's a complicated story to tell end-users, but anything else is misleading. One hopes that any new feature we that gets wide implementation and is not explicitly performance oriented pays for itself on a semantic basis. Such features find their natural users prior to the optimization foot race kicking off, and there's nothing bad about any of that. The ideal world (that freeze() is now a poster child for) looks roughly like: // Standard written, implementations arrive (not in that order) // ...time passes... Hooray! New features! // ...time passes... // Users realize optimization is uneven Boo! They're slow! // Said without any sense of JS perf history // ...time passes... // Features optimized Yay! They're fast! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A case for removing the seal/freeze/isSealed/isFrozen traps
David, that's great clarification, and indeed it looks a bit different from that perspective. Still the only use case I see for freezing/sealing whole object (the way it works now) is when we expose some constant dictionary object on which each property counts, and that's very rare use case. I don't see much good in disallowing extensions to prototypes we expose. it's not JS way. We can prevent accidental modifications of *existing* API's but disallowing custom extensions is too restrictive and not friendly in my opinion. -- View this message in context: http://mozilla.6506.n7.nabble.com/A-case-for-removing-the-seal-freeze-isSealed-isFrozen-traps-tp272443p272674.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A case for removing the seal/freeze/isSealed/isFrozen traps
Le 15/02/2013 11:03, Mariusz Nowak a écrit : I've worked a lot with ECMAScript5 features in last two years, and I must say I never found a good use case for Object.freeze/seal/preventExtensions, it actually raised more issues than it actually helped (those few times when I decided to use it). Currently I think that's not JavaScript'y approach and use cases mentioning "untrusted parties" sounds "logical" just in theory, in practice when actually we never include "untrusted" modules in our code base does not make much sense. However, main point I want to raise is that several times I had a use case for very close functionality, that with current API seem not possible: I'd like to be able to *prevent accidental object extensions*. If something *accidental* can happen, then "untrusted parties" is more than theorical ;-) Brendan says it better [1]: "In a programming-in-the-large setting, a writable data property is inviting Murphy's Law. I'm not talking about security in a mixed-trust environment specifically. Large programs become "mixed trust", even when it's just me, myself, and I (over time) hacking the large amount of code." "Security" and "untrusted parties" aren't about terrorists groups trying to hack your application to get a copy of your database or corrupt it or your choice to use some code downloaded from a dark-backgrounded website. They're about you trying to meet a deadline and not having time to read carefully the documentation and comments of every single line of modules you're delegating to. Trust isn't an all-or-nothing notion. Anytime I say "untrusted", I should probably say "partially trusted" instead. Trust also changes over time, mostly because as times passes, our brains forget the invariants and assumptions we baked in our code and if those aren't enforced at compile time or runtime, we'll probably violate them at one point or another and thus create bugs. Or we just make mistakes, because we're human and that's exactly the case you're explaining. "Security" and "untrusted parties" are about our inability as human beings to remember everything we do and our inability to be perfect. Any "security" mechanism is a mechanism to protect against hostile outsiders but also and probably mostly ourselves over time. It is usually not considered so, but separation of concerns is a security mechanism in my opinion. So are most object-oriented so-called good practices. "Security" is very loaded with emotions of people afraid to have their password stolen and "cyber attacks". It's also loaded with the notion of human safety and human integrity which, as human beings are sensitive to. Maybe I should start using a different word... I want to control all enumerable properties of the object, so they can only be set via defineProperty, but any direct assignment of non existing prop e.g. 'x.notDefinedYet = value' will throw. Imagine some ORM implementation, that via setters propagates changes to underlying persistent layer, at this time we cannot prevent accidental property sets that may occur before property was actually defined (therefore not caught by the setter) I assume that proxies will make such functionality possible, but maybe some Object.preventUndefinedExtensions will be even better. The problem is that there are probably dozens of use cases like yours [2] and the Object built-in can't welcome them all. Hence proxies as an extension mechanism of any "random micro-abstraction" (as Andreas Rossberg puts it ;-) ) David [1] https://mail.mozilla.org/pipermail/es-discuss/2013-February/028724.html [2] When I learned JS, how many time did I mistyped .innerHTML and wasted hours not understanding where some "undefined" string in my UI came from. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A case for removing the seal/freeze/isSealed/isFrozen traps
I like this direction: it would distinguish the user-level operation _assignment_ from the meta-level operation _definition_. I’m not sure where `delete` fits in, but it’s much less common, so less of a potential problem. On Feb 15, 2013, at 11:03 , Mariusz Nowak wrote: > > I've worked a lot with ECMAScript5 features in last two years, and I must say > I never found a good use case for Object.freeze/seal/preventExtensions, it > actually raised more issues than it actually helped (those few times when I > decided to use it). Currently I think that's not JavaScript'y approach and > use cases mentioning "untrusted parties" sounds "logical" just in theory, in > practice when actually we never include "untrusted" modules in our code base > does not make much sense. > > However, main point I want to raise is that several times I had a use case > for very close functionality, that with current API seem not possible: > I'd like to be able to *prevent accidental object extensions*. I want to > control all enumerable properties of the object, so they can only be set via > defineProperty, but any direct assignment of non existing prop e.g. > 'x.notDefinedYet = value' will throw. Imagine some ORM implementation, that > via setters propagates changes to underlying persistent layer, at this time > we cannot prevent accidental property sets that may occur before property > was actually defined (therefore not caught by the setter) > I assume that proxies will make such functionality possible, but maybe some > Object.preventUndefinedExtensions will be even better. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A case for removing the seal/freeze/isSealed/isFrozen traps
I've worked a lot with ECMAScript5 features in last two years, and I must say I never found a good use case for Object.freeze/seal/preventExtensions, it actually raised more issues than it actually helped (those few times when I decided to use it). Currently I think that's not JavaScript'y approach and use cases mentioning "untrusted parties" sounds "logical" just in theory, in practice when actually we never include "untrusted" modules in our code base does not make much sense. However, main point I want to raise is that several times I had a use case for very close functionality, that with current API seem not possible: I'd like to be able to *prevent accidental object extensions*. I want to control all enumerable properties of the object, so they can only be set via defineProperty, but any direct assignment of non existing prop e.g. 'x.notDefinedYet = value' will throw. Imagine some ORM implementation, that via setters propagates changes to underlying persistent layer, at this time we cannot prevent accidental property sets that may occur before property was actually defined (therefore not caught by the setter) I assume that proxies will make such functionality possible, but maybe some Object.preventUndefinedExtensions will be even better. Brendan Eich-3 wrote: > > Andreas Rossberg wrote: >> On 14 February 2013 19:16, David Bruant wrote: >>> Le 14/02/2013 18:11, Andreas Rossberg a écrit : You're being vastly over-optimistic about the performance and the amount of optimisation that can realistically be expected for proxies. Proxies are inherently unstructured, higher-order, and effectful, which defeats most sufficiently simple static analyses. A compiler has to work much, much harder to get useful results. Don't expect anything anytime soon. >>> var handler = {set: function(){throw new TypeError}} >>> var p = new Proxy({a: 32}, handler); >>> >>> p.a; >>> >>> It's possible *at runtime* to notice that the handler of p doesn't have >>> a >>> get trap, optimize p.[[Get]] as target.[[Get]] and guard this >>> optimization >>> on handler modifications. Obviously, do that only if the code is hot. >>> I feel it's not that much work than what JS engines do currently and the >>> useful result is effectively getting rid of the forwarding overhead. >>> Is this vastly over-optimistic? >> >> Yes. Proxies hook into many different basic operations, and there are >> many special cases you could potentially optimise for each of them, >> many of which don't come for free. I very much doubt that any vendor >> currently has serious plans to go down that rathole instead of >> spending their energy elsewhere. Certainly not before it is clear how >> (and how much) proxies will actually be used in practice. > > You're right in general, and we have not optimized, e.g. inlining > scripted trap calls. > > We did do something special for our new DOM bindings I wanted to pass > along, in case anyone is interested: > > https://bugzilla.mozilla.org/show_bug.cgi?id=769911 > > Thanks to bz for the link. This is yet another inline cache > specialization for expandos on nodelists. > > /be > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > - Mariusz Nowak https://github.com/medikoo -- View this message in context: http://old.nabble.com/A-case-for-removing-the-seal-freeze-isSealed-isFrozen-traps-tp35013883p35026595.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array subclassing, .map and iterables (Re: Jan 30 TC39 MeetingNotes)
I'd say that either we properly clean up the Array hierarchy, or we leave it alone. A half-baked solution that only applies to typed arrays, and divorces them from the Array hierarchy, seems less attractive than just doing the naive thing, i.e., TypedArray< Array. Agree with that, and I'll go further: we should leave alone what's already shipped and in use for a long time. TypedArray < Array sounds good to me. The question is how to clean up/refine the class hierarchy with the existing language means. Consider a hypothetical FixedLengthArray < Array and a FixedLengthTypedArray that inherits from both branches. More immediately relevant for this thread, I would like to see Array < Container with map, from, filter, and perhaps some others, moving from Array to Container. Then Map and Set would be Containers, supporting operations currently limited to Array (WeakMap is probably too special to be a normal Container). Claus ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss