I think the problem is not the existence of the invoke trap but the advice we've talked about for using it. And I think this lesson applies to all derived traps.
To maintain consistency, we should always advise overriding fundamental traps first, and then consistent behavior for derived traps comes along for the ride. We should only advise overriding derived traps for one of the following two purposes: 1) To optimize the implementation of the behavior that would have followed anyway from overriding the fundamental traps. Since this should be observably equivalent to not overriding these derived traps, consistency between fundamental and derived is maintained. 2) When one intends to create an inconsistency between fundamental and derived, purposely breaking a consistency that usually holds in the language. These cases should be exceedingly rare, and most apparent occurrences of these cases should be viewed with great suspicion, as they are probably design mistakes. Note that these two reasons are uncomfortably coupled: #1 only preserves equivalence given that #2 is not encountered in #1's target. I think the only conceptual difference between invoke and the other derived traps is that invoke is our only doubly-derived trap. On Fri, Sep 20, 2013 at 11:17 AM, Tom Van Cutsem <[email protected]> wrote: > 2013/9/20 Jason Orendorff <[email protected]> > >> OK, taking all that at face value, what's the justification for .hasOwn()? >> >> a) allows more direct interception of Object.prototype.hasOwnProperty() >> b) potentially less allocations each time someone calls .hasOwnProperty(). >> >> I think .hasOwn() should be removed. >> > > I assume you're making the case to remove all derived traps then, not just > hasOwn()? > > The question is where to draw the line. get() and set() are also derived > traps: they can be defined in terms of > getOwnPropertyDescriptor/defineProperty, but here the "overhead" of always > having to work with descriptors really becomes manifest. Do you think they > should also be removed? > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
