iterator as a unique name and the enumerate trap
2012/10/1 David Bruant <bruant.d at gmail.com>
What about making "enumerator" a unique name and remove the enumerate trap too? Proxies that want to redefine the behavior of for-in loop can just decide to return a different iterator than the target one.
Are you proposing that the unique symbol "enumerator" would then also allow regular (non-proxy) objects to customize old for-in loops? If not, then it makes little sense to change the interface from a trap to a unique name for proxies.
If yes, then we should ask ourselves the question: is this a useful hook for regular objects to customize? I think it's not, really (bear in mind that enumeration can only generate strings (property names), it's a good deal less generic than iteration)
2012/10/1 Tom Van Cutsem <tomvc.be at gmail.com>
If yes, then we should ask ourselves the question: is this a useful hook for regular objects to customize? I think it's not, really (bear in mind that enumeration can only generate strings (property names), it's a good deal less generic than iteration)
Put another way: customizing enumeration is meta-programming, customizing iteration is not.
2012/10/1 Tom Van Cutsem <tomvc.be at gmail.com>
2012/10/1 Tom Van Cutsem <tomvc.be at gmail.com>
If yes, then we should ask ourselves the question: is this a useful hook for regular objects to customize? I think it's not, really (bear in mind that enumeration can only generate strings (property names), it's a good deal less generic than iteration)
Put another way: customizing enumeration is meta-programming, customizing iteration is not.
I had not seen things from that angle, but it seems like a valid reason for the apparent inconsistent of the proxy handler API.
On Oct 1, 2012, at 6:56 AM, David Bruant wrote:
2012/10/1 Tom Van Cutsem <tomvc.be at gmail.com> 2012/10/1 Tom Van Cutsem <tomvc.be at gmail.com> If yes, then we should ask ourselves the question: is this a useful hook for regular objects to customize? I think it's not, really (bear in mind that enumeration can only generate strings (property names), it's a good deal less generic than iteration)
Put another way: customizing enumeration is meta-programming, customizing iteration is not. I had not seen things from that angle, but it seems like a valid reason for the apparent inconsistent of the proxy handler API.
I actually think they are both meta-programming hooks, in that they both provided a means for extending the behavior of syntactic constructs of the language. However, I still come to the same conclusion:
Defining for-of iteration has high utility and will occur frequently so it should be exposed via a light-weight extension mechanism: a unique name (symbol). Extending for-in enumeration is of little utility and will occur infrequently. For that reason it makes sense for it to be exposed by the more heavy weight proxy extension mechanism.
If I'm following properly, iterate is now a unique name that can be used on any object as per July 24 meeting notes [1]. It led the decision to remove the iterate trap on proxies [2]: "Removed ''iterate()'' trap as iterators can be defined on any old object via an ''iterate'' unique name. See discussion at [[harmony:iterators]]. A proxy will intercept the request for its iterator via the ''get'' trap, which is passed the unique ''iterator'' name as argument."
What about making "enumerator" a unique name and remove the enumerate trap too? Proxies that want to redefine the behavior of for-in loop can just decide to return a different iterator than the target one.
David
[1] esdiscuss/2012-July/024207 [2] harmony:direct_proxies#open_issues