[[Enumerate]] and enumerate and keys trap
waldron.rick at gmail.com
Mon Oct 8 11:03:23 PDT 2012
On Mon, Oct 8, 2012 at 1:57 PM, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
> 2012/10/8 Allen Wirfs-Brock <allen at wirfs-brock.com>
>> 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
> 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
> I'm all for internal spec refactorings to avoid duplication, but I feel
> this particular refactoring is better left invisible to users.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss