3 ms·

The Java `Iterator` interface has a `remove` method, that in my experience is rarely used. Apparently rarely enough that it wasn't even a concern when hiding t

The Java `Iterator` interface has a `remove` method, that in my experience is rarely used. Apparently rarely enough that it wasn't even a concern when hiding the `Iterator` instance in its foreach loop implementation. Otherwise, this seems like a case of operator overloading. Sure, as long as `continue` and `break` do something like they're supposed to, it works. But how often is that true, when it's also NOT true that simply implementing something like an `Iterator` interface with a fixed implementation of those operators? If the only advantage is in providing the ability to break expectations, that's probably just a bad idea.

adamrezich 5y ago
since there's no such things as iterators in this language, it's the responsibility of the programmer of the for_expansion to make the keywords do what makes sense in the context of iterating over the struct in a for loop. I don't understand why you think it's a bad idea. you write a struct for your data container, you write a for_expansion that allows for it to be iterated over in a for loop, and you optionally define what break, continue, and remove do in the context of the for_expansion you wrote. it's not as open to unexpected craziness as operator overloading can be because these keywords only work in the context of a for loop, and you are defining how a for loop is handled for your struct... where's the issue?
- jdmichal 5y ago
  The issue is that those keywords are expected to work a particular way, just like operators. Just like the operator + is expected to do some sort of addition operation, the keyword `break` is expected to do some sort of loop exit operation. The ability to reprogram the break operator to do anything else isn't useful for anything other than breaking expectations. And having to program the same break mechanics into every single iterable type rather than simply implementing an `Iterator` interface which then has those operators implemented seems less optimal. Which is why I said, it seems like the only advantage is the ability to break expectations. Which is arguably, realistically a disadvantage.

adamrezich 5y ago

since there's no such things as iterators in this language, it's the responsibility of the programmer of the for_expansion to make the keywords do what makes sense in the context of iterating over the struct in a for loop. I don't understand why you think it's a bad idea. you write a struct for your data container, you write a for_expansion that allows for it to be iterated over in a for loop, and you optionally define what break, continue, and remove do in the context of the for_expansion you wrote. it's not as open to unexpected craziness as operator overloading can be because these keywords only work in the context of a for loop, and you are defining how a for loop is handled for your struct... where's the issue?

jdmichal 5y ago
The issue is that those keywords are expected to work a particular way, just like operators. Just like the operator + is expected to do some sort of addition operation, the keyword `break` is expected to do some sort of loop exit operation. The ability to reprogram the break operator to do anything else isn't useful for anything other than breaking expectations. And having to program the same break mechanics into every single iterable type rather than simply implementing an `Iterator` interface which then has those operators implemented seems less optimal. Which is why I said, it seems like the only advantage is the ability to break expectations. Which is arguably, realistically a disadvantage.