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
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
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
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).
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
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
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.
... 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
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
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
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
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
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
13 matches
Mail list logo
