Protected properties using Name objects

David Bruant bruant.d at gmail.com
Fri Jun 15 14:40:41 PDT 2012


Le 15/06/2012 21:27, Brandon Benvie a écrit :
> Currently there's no way to have a data property that is writable by
> some but not all.
My heartbeat reaction to this first sentence is: is it a use case anyway?

> This can't even really be achieved with accessors or proxies directly.
> Rather, the underlying data is mutated through some other avenue, and
> the value returned on access comes from this secondary source. Neither
> method of course is remotely as efficient as a real data property as
> either.
I disagree with that statement (but until direct proxies are efficiently
implemented, it's hard to tell who is right :-) ).

var o = {a:1, b:2};
var o2 = makeProxyWithSomeReadOnlyProperties(o, ['a']);

The makeProxyWithSomeReadOnlyProperties creates a proxy with o as
target. Only property-mutation-operation traps need to be implemented
("read" traps are the forward-to-target default ones). In this
configuration, at least the reads on o2 can be made as efficient as the
read in o (since the engine knows the target and knows that "read" traps
are the default ones, so it can delegate the operation to the target
with no overhead)

There is certainly an overhead for write operations (since you need to
check whether the property is readOnly or not). It is unclear whether
it's so much more than it wouldbe natively to justify a direct native
implementation in my opinion.
The reason why it's unclear is also that a new property descriptor
attirbute like the one your propose may deteriorate the performance of
all write operations on all objects (since a new check may be necessary).


It seems to me that your proposal could be implemented in pure ES.next
(not on existing objects, though). I'd be interested in seeing it
implemented and used in real world examples. Only then will we be able
to tell whether there are use cases and whether, on these use cases, the
performance is bad enough and not improvable to justify native
implementations.

A nit on your API:
"Object.protectProperty(object : Object, currentProtector : Name) -> true
unprotects the key on object which currentProtector protects"
=> I don't think Object.protectProperty should ever "unprotect" something.

David


More information about the es-discuss mailing list