Virtual extension methods -- a strawman design

[Pavel Minaev]

On Mon, May 17, 2010 at 2:45 AM, Gernot Neppert <mcnepp02 at googlemail.com> wrote:

> 2010/5/17 Pavel Minaev <int19h at gmail.com>:> On Mon, May 17, 2010 at 12:47 AM, Gernot Neppert <mcnepp02 at googlemail.com>
> > wrote:
> >
> > Similar reasoning is applicable to Collection#contains, Collection#isEmpty,
> > Collection#toArray, List#get, List#indexOf, List#lastIndexOf - and probably
> > more. Consequently, I'd expect all those to be lifted up to Iterable in
> > conjunction with this proposal, with default implementations provided there.
>
> Hmm, I definitely hope this won't happen ;-)
>
> Iterable is quite useful as it is now. It's name conveys the purpose:
> provide an iterator that can be used to implement for-style loops.
>  Why would you want to blur the distinction between Iterables and Collections?

It's not that I "want" to blur the distinction. The point is that the
existing interface of Iterable already implies all those other
operations - since they are all trivially implementable in terms of
iterators - and you can have them today with static helpers. The only
difference between having them as part of an interface or not is
whether a particular implementation can elect to provide them in a
more efficient way.

If any Iterable can immediately support those operations, why _not_
have them in the interface? The old reasoning was that the burden on
implementers would be too high. What else is there?

> Actually, this makes me fear a new trend: Will people move as many
> methods as far 'upwards' as possible, providing more or less
> meaningful default implementations?

I'd expect so. Why do you fear it? It means that many algorithms could
be written in a more generic way than they are today. Where today you
have to accept Collection, solely because you need size() on it, you'd
be able to accept an Iterable instead, and be just as efficient as
before when someone passes you a Collection. More genericity is good;
why fear it?

By the way, there's one other aspect of it. When you provide a default
implementation, you are, effectively, codifying a formal "as-if"
contract for a given method. I think that it is better than
long-winded natural language descriptions.