V2User wrote: ↑22 Aug 2023, 04:32
But this will throw an error saying that it's not enumerable. Obviously, what it said is against the fact. As
array is certainly enumerable.
It's not saying
Array is not enumerable, it's saying the
c instance of class
CCC is not enumerable. And it isn't, because it breaks the enumerable contract that "
__Enum should return an enumerator which will return items contained by the object" or (at least for
for loops) that the object should have an "enumerator-compatible Call method".
With your
CCC class,
__Enum is not returning an enumera
tor, it's returning an enumera
ble. As just me showed, it's trivial to pass through that enumerable's enumerator as the parent object's enumerator and thereby satisfy the contract.
If the language was adjusted to support returning an enumerable instead of an enumerator from the
__Enum method of an enumerable object, would you expect it to recursively attempt to discover enumerators on returned objects? That is, do you believe the language should support this structure:
for v in {__Enum: (p*) => {__Enum: (p*) => {__Enum: (p*) => [1, 2, 3, 4].__Enum(p*)}}}
And what if one of the sub-objects was both an enumerator, and enumerable? As in this code:
for v in {__Enum: (p*) => {Call: ((&v) => v := 4), __Enum: (p*) => {__Enum: (p*) => [1, 2, 3, 4].__Enum(p*)}}}. Should this code enumerate
4 over and over, or should it enumerate
1, 2, 3, 4?
And if AutoHotkey did accept enumerables instead of enumerators by some method (recursion or otherwise), what practical advantage might that offer over (as just me showed) simply returning the enumerator of that enumerable as was originally designed?