My ECMAScript 7 wishlist
bruant.d at gmail.com
Fri Jun 6 09:06:03 PDT 2014
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 :-)
> 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)
> 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
>> 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
>> 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.
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss