The word "select" simply came from my exposure to .NET. Actually, I
find the word "project" (as a verb) to be more appropriate, though I
agree "map" is fine too.
I don't think the precise name is going to matter too much.
Sure.
It will depend on how one intends to use it. Again, because I am
following the .NET model, Iterable is the first choice only due to
that.
However, it's worth pointing out that Iterable allows for sequences
larger than 2GB items, while extending AbstractList or
AbstractCollection, because those classes use an int to describe
their length (and in the case of AbstractList, to enumerate as
well).
Good point; I hadn't thought of that. Still, as the underlying structure
is already one that is constrained by the 2^31 -1 limit (being, in the
OP's case, a java.util.List), and considering how the overwhelming
majority of use-cases would fall hither of that limit, I think it would
be safe to code for these uses. Might of course make the Iterable
available, too.
Also, using Iterable means that the code is usable for a broader
range of inputs. I.e. is more re-usable. Extending AbstractList or
AbstractCollection will limit the uses to wrapping lists or
collections.
Now I'm not sure you got what I meant. I meant that the content-mapping
code you showed for Iterable structures could be extended so that the
"view" objects would be Collections, when mapping the contents of any
class implementing Collection, or Lists, when mapping the contents of
any class implementing List; and that it's very easy to do by making the
"view" Object extend Abstract(Collection|List), because you only have a
very few methods to implement (provided you make them read-only -- if
they're writable it becomes slightly more tricky).
I agree that Iterable is an interface that serves broader purposes and
can be implemented by a wider range of objects than Collection et al.,
but nevertheless a great share of the code (my code, at least) consists
of working with Collections. It's fine if it's broad, but not if it
being broad lessens its usefulness.
..NET addresses that lack by including the extension method Count()
(in my code, that would show up as a static method in the Iterables
class), which checks for common interfaces that support a direct
retrieval of the collection length, and if those are not available,
then enumerates the entire collection as a fall-back.
Is that the equivalent of this "defender methods" stuff I've been
hearing about?
I'm not sure I'd call that the _main_ advantage. In fact, it can be a
bit of a pitfall in .NET, as chained enumerators are all re-run each
time you enumerate the last link of the chain.
Not only is it a potential performance issue, variable capturing can
result in some non-intuitive (and often unintended) results, because
even the parameters of the enumerations may be changed after the
fact, having effect on subsequent enumerations of the new enumerable
object.
But it definitely can be a very handy aspect of the approach, if one
is careful to mind the implications of the implementation.
Sorry but you totally lost me there.
I wouldn't claim for a second that these things are going to be very
efficient. To me, the main use is as a specific "view" of a given
structure, short-term objects which I'm going briefly to manipulate and
then discard. In those cases, there is next to no performance impact,
because what the view is doing, I would have to do if I didn't have it
-- it just hides it and provides a handy syntax, making the application
logic clearer.