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
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 Bruantbruan...@gmail.com 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: 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 medikoo+mozilla@medikoo.com 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
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
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: Are frozen Objects faster ?
On Thursday, February 14, 2013, Andreas Rossberg wrote: On 14 February 2013 19:26, Herby Vojčík he...@mailbox.sk javascript:; 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
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 medikoo+mozilla@medikoo.com 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: 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 bben...@mozilla.com 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 medikoo+mozilla@medikoo.com 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
On Fri, Feb 15, 2013 at 9:24 AM, Erik Arvidsson erik.arvids...@gmail.comwrote: ... and security sensitive code could just ban/alter the reflection methods. On Feb 15, 2013 8:29 AM, Brandon Benvie bben...@mozilla.com 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
On 15 February 2013 14:29, Brandon Benvie bben...@mozilla.com 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: 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
rossb...@google.com mailto:rossb...@google.com wrote:
On 14 February 2013 21:36, Andrea Giammarchi
andrea.giammar...@gmail.com 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: 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 slightly...@google.comwrote: On Thursday, February 14, 2013, Andreas Rossberg wrote: On 14 February 2013 19:26, Herby Vojčík he...@mailbox.sk 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
[].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
