My ECMAScript 7 wishlist

[David Bruant]

Le 06/06/2014 17:47, Frankie Bagnardi a écrit :
> Couldn't preventUndeclaredGet() be implemented with proxies?
Yes it can. Doing it left as an exercise to the reader... Wait... Don't 
bother, Nicholas did it :-)
http://www.nczonline.net/blog/2014/04/22/creating-defensive-objects-with-es6-proxies/

> It actually sounds like an extremely useful feature for development 
> builds of libraries and applications.  Typos are very very common, and 
> often difficult to look over while debugging.  On the other hand, it 
> would break a lot of existing code if you try to pass it as an object 
> to a library; you'd have to declare every possible value it might 
> check (which isn't necessarily bad).  Most of the time, it's just an 
> options object, or an object it'll iterate over the keys of.
>
> Using it on arrays would also reduce off-by-1 errors (though I don't 
> see them often in JS).
Ever since I've started using forEach/map/filter/reduce, I haven't had 
an off-by-one error on arrays. Highly recommanded! (I think I've heard 
Crockford making the same recommandation in a recent talk, but I cannot 
find the link)

David

>
>
>
>
> On Fri, Jun 6, 2014 at 7:37 AM, David Bruant <bruant.d at gmail.com 
> <mailto:bruant.d at gmail.com>> wrote:
>
>     Le 06/06/2014 15:57, Mark S. Miller a écrit :
>>     By contrast, a Map's state is more like the private instance
>>     variable state of a closure or a post-ES6 class.
>     The capabilities to arbitrarily modify Maps (set/delete on all
>     keys, with any values) will be expected by any ES6-compliant code
>     to be globally available, so a Map's state cannot reasonably be
>     considered private.
>     This differs from the state of a closure where its access is
>     strictly moderated by the public API giving access to it and to
>     the fact that this API is not provided globally (unlike
>     Map.prototype).
>
>
>>     Object.freeze of a Map should not alter the mutability of this
>>     state for the same reason it does not alter the state captured by
>>     a closure or a future class instance.
>     I'd argue the Map state is very much like regular objects (for
>     which you can't deny [[Set]], [[Delete]], etc.), not closure's state.
>
>     In an ES6 world, denying access to the global Map.prototype.*
>     would break legitimate code, so that's not really an option
>     confiners like Caja could provide.
>
>
>>
>>
>>         or should an Object.makeImmutable be introduced? (it would be
>>         freeze + make all internal [[*Data]] objects immutable)
>>
>>
>>     We do need something like that. But it's a bit tricky. A client
>>     of an object should not be able to attack it by preemptively
>>     deep-freezing it against its wishes.
>     I don't see the difference with shallow-freezing?
>     It's currently not possible to defend against shallow-freezing (it
>     will be possible via wrapping in a proxy).
>
>
>>
>>>         This can be achieved with Proxy right, or is that too
>>>         cumbersome?
>>         Code-readability-wise, wrapping in a proxy is as cumbersome
>>         as a call to Object.preventUndeclaredGet I guess.
>>
>>         This sort of concerns are only development-time concerns and
>>         I believe the runtime shouldn't be bothered with these (I'm
>>         aware it already is in various web). For instance, the
>>         TypeScript compiler is capable today of catching this error.
>>         Given that we have free, cross-platform and fairly easy to
>>         use tools, do we need assistance from the runtime?
>>
>>
>>     Yes. Object.freeze is a runtime production protection mechanism,
>>     because attacks that are only prevented during development don't
>>     matter very much ;).
>     Just to clarify, I agree that Object.freeze was necessary in ES5
>     (have we had proxies, it might have been harder to justify?),
>     because there was no good alternative to protect an object against
>     the parties it was shared with.
>     But the concern Nicholas raises doesn't seem to have this
>     property. Reading a property that doesn't exist doesn't carry a
>     security risk, does it? Object.preventUndeclaredGet doesn't really
>     protect against anything like ES5 methods did.
>
>     David
>
>     _______________________________________________
>     es-discuss mailing list
>     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>     https://mail.mozilla.org/listinfo/es-discuss
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140606/8b0a4ce0/attachment-0001.html>