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<bruan...@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
