[Wish:] Wish __enum() could support any enumerable objects. Topic is solved

[V2User]

Wish __enum() could support any enumerable objects, not only enumerators. I wish this code below could be supported:

Code: Select all

class CCC{
	__Enum(num)=>[1,2,3,4,5]
}
c:=CCC()
for x in c{
	OutputDebug(x)
}

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.

image.png (38.3 KiB) Viewed 1421 times

[just me]

Code: Select all

class CCC{
	__Enum(num)=>[1,2,3,4,5].__Enum(num)
}
c:=CCC()
for x in c{
	MsgBox(x)
}

[geek]

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 enumerator, it's returning an enumerable. 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?

[V2User]

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 enumerator, it's returning an enumerable. 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?

@just me @geek Thank you for your answer. I think I might get it now.