Type of property names, as seen by proxy traps

David Bruant david.bruant at labri.fr
Thu Jul 7 07:12:53 PDT 2011

Le 07/07/2011 15:42, Andreas Rossberg a écrit :
> On 7 July 2011 15:09, David Bruant<david.bruant at labri.fr>  wrote:
>>> Yes, that's what I would propose, too. It's just a bit ugly that we
>>> have to do that in two places now.
>> Three if counting the "enumerate" trap for for-in loops. Regardless of
>> ugliness, it's necessary. keys and enumerate are derived traps. They have a
>> default implementation for developer convenience, however, developers could
>> decide to reimplement the trap and the proxy engine implementation have to
>> enforce types anyway. Each trap has to be guarded independently.
>> Derived traps as showed are written in JS for expository purposes. Engines
>> will be free to optimize as they wish internally as long as the observed
>> behavior is the same.
> True, but optimizing that actually is more tricky than you might
> think, since in general it would change the semantics if an engine
> decided to call toString only once. It has to make sure that none of
> the names are objects, or at least none of their toString methods was
> modified and they are all free of side effects.
However, I'm not sure side-effects are a problem.
var o = {a:1, toString:function(){o.b = 12; return 'a'; }};
console.log(o[o], o.b); // 1, 12 on Firefox 5
Here, o[o] triggers a side effect and that sound like the normal behavior.
I agree that performance is an issue, but as you say below, programmers 
returning objects as property names are aware of the performance issue.

>> Specifically, I think that type inference engines can
>> be of a great help in ensuring that types are correct without having to pay
>> the price of looking at every single element independently.
> I don't think that the type checks are the biggest cost. Doing the
> actual conversion several times for those cases where the type is
> _not_ string is potentially much more expensive.
> I guess it's fine if programmers suffer for returning objects as
> property names. But something like integers might be a valid use case.
Is there a solution at all to that problem? If we want to enforce the 
invariant, we have to pay the cost. I don't see a workaround... or 
maybe, instead of returning an array with names, the traps could return 
a proxy that lazily coerces types on getting? :-p


More information about the es-discuss mailing list