On Mon, Oct 8, 2012 at 1:57 PM, Tom Van Cutsem <[email protected]> wrote:
> 2012/10/8 Allen Wirfs-Brock <[email protected]> > >> >> With the [[Enumerate]] trap parameters I was trying to minimize the >> number of essential internal methods. I don't see why we couldn't carry >> that forward to traps. A single [[GetPropertyKeys]] internal method/trap >> with includePrototype and onlyEnumerable arguments would seem to cover the >> all of the use cases of the enumerate, keys and getOwnPropertyNames traps. >> Why not just have that single trap? >> > > I prefer the current symmetry with the existing built-ins: > > Object.keys(proxy) // triggers handler.keys(target) > Object.getOwnPropertyNames(proxy) // triggers > handler.getOwnPropertyNames(target) > > It's just more learnable and consistent than routing these through a > getPropertyKeys trap. > > Also, in a previous attempt to merge operations into a single trap > (freeze, seal, preventExtensions) we eventually circled back and left them > separate, on the grounds that most of the time you'd end up having to > dispatch based on the arguments to a dedicated operation anyway. > Additionally, if your defining a target, you could just as easily define one trap handler and assign it to all traps and do the dispatch _anyway_ (default handler?). I completely agree with the symmetrical approach, anything else will break intuition. (no silver bullet, but counts for something) Rick > > I'm all for internal spec refactorings to avoid duplication, but I feel > this particular refactoring is better left invisible to users. > > Cheers, > Tom > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
