Comment by tamplinjohn: You could return the array in the immutable case if the compiler knew it wasn't going to get modified in this particular case. Taking the idea from the other thread, the default implementation could be the safe one and a method call generator could generate a faster implementation when told by the compiler the result was only used in a read-only manner.
The downside of internal iterators are that you waste space in the object for its lifetime (even if it is a number of null references), and you can't have multiple iterators in progress on the same object at once. In your example, if f called something that wanted to iterate on lightweightArray, it can't (or if it does, internally it has to be creating essentially an external iterator plus the extra overhead to keep track of them rather than letting callers manage them). Additionally, you are creating an object for the callback (though the compiler might be able to remove the object allocation if it were smarter than it is today) so it isn't clear where the win is. For more information: http://code.google.com/p/google-web-toolkit/wiki/LightweightCollections --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
