Type of property names, as seen by proxy traps

Andreas Rossberg rossberg at google.com
Thu Jul 7 06:42:00 PDT 2011

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.

> 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.


More information about the es-discuss mailing list