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 <bruan...@gmail.com
<mailto:bruan...@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@mozilla.org <mailto: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
