[].push wrt properties along the [[Prototype]] chain

2013-02-15 Thread Jeff Walden
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 ?

2013-02-15 Thread Andrea Giammarchi
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 ?

2013-02-15 Thread Aymeric Vitte
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

2013-02-15 Thread Andreas Rossberg
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

2013-02-15 Thread Russell Leggett
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

2013-02-15 Thread Erik Arvidsson
... 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

2013-02-15 Thread Brandon Benvie
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 ?

2013-02-15 Thread Alex Russell
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

2013-02-15 Thread medikoo
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

2013-02-15 Thread David Bruant

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

2013-02-15 Thread Axel Rauschmayer
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

2013-02-15 Thread Mariusz Nowak

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)

2013-02-15 Thread Claus Reinke

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