[[Enumerate]] and enumerate and keys trap

Rick Waldron 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
> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121008/815fec39/attachment.html>


More information about the es-discuss mailing list