2012/11/13 Erik Arvidsson <[email protected]> > On Tue, Nov 13, 2012 at 3:25 PM, Tom Van Cutsem <[email protected]>wrote: > >> >> So, my proposal: let's revert the fundamental traps of Handler to become >> abstract methods again. This forces subclasses of Handler to provide all >> fundamentals at once, avoiding the footgun. >> > > Maybe we should skip the derived traps for ES6 and see if the extra > allocation really becomes an issue in reality? This way we are keeping the > API smaller and the risk of errors lower. We can always add the derived > traps later, can't we? >
I would subscribe to this point of view if only all derived traps were as trivial to remove as the "has" or "hasOwn" traps that were brought up by Allen in this thread. Looking at the full list of fundamental vs derived traps < http://wiki.ecmascript.org/doku.php?id=harmony:virtual_object_api>, it quickly becomes apparent that there are far more derived than fundamental traps. It'll be a challenge to try and get rid of all derived traps. Now scroll down to the "non-normative implementation" section of that wiki page and have a look at the default implementation of "hasOwn". It's only 3 lines, making it by far the shortest derived trap. Many of the other ones (e.g. keys() and enumerate()), perform spurious property descriptor allocations in a for-loop, making the allocation overhead linear instead of constant. As Allen mentioned himself, the "hasOwn" trap was a good case to bootstrap the discussion because of its simplicity: it's easy to understand the inconsistencies, it's easy to get rid of, and the extra allocation cost is minimal. The story is not so simple for the other derived traps. All of this is just to adjust the bias that getting rid of all derived traps would be an easy thing to do. Cheers, Tom
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
