[[Enumerate]] and enumerate and keys trap

Allen Wirfs-Brock allen at wirfs-brock.com
Mon Oct 8 11:20:07 PDT 2012


On Oct 8, 2012, at 10:57 AM, Tom Van Cutsem 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.

Then we should also have the enumerate 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.

However, internal method have to be dispatched at a very low level of an implementation.  In some implementations there might be a runtime cost to having a larger number of them.   On the other hand, pushing dispatching into the handler certainly has a cost.  I could speculate that these are relatively rare operations (compared to most other internal methods) and if having a larger number of internal methods carried any intrinsic runtime performance cost it would be better to place the cost on the actual use of the internal methods/traps in question. 


> 
> I'm all for internal spec refactorings to avoid duplication, but I feel this particular refactoring is better left invisible to users.

I definitely want the internal methods and traps to be completely parallel.  If we take the path suggested above I will add the equivalent of [[keys]] and  [[getOwnPropertyNames]] as essential internal methods and get rid of the parameters to [[Enumerate]].

If that is the consensus, it should probably be captured as a spec. bug report.


Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121008/e1bbf8f4/attachment.html>


More information about the es-discuss mailing list