Couldn't preventUndeclaredGet() be implemented with 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). On Fri, Jun 6, 2014 at 7:37 AM, David Bruant <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 > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
