On 7 July 2011 15:09, David Bruant <[email protected]> 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. /Andreas _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
