List of all default methods

Jochen Theodorou blackdrag at gmx.org
Thu Nov 21 07:22:52 PST 2013


Am 21.11.2013 15:56, schrieb Brian Goetz:
[...]
> Yes!  All the other methods on List (add, remove, retainAll) are
> in-place mutative.  The standard way to sort a List is
> Collections.sort(List), which is also in-place (and less efficient). The
> new method on List is simply Collections.sort(List), but in the right
> place, and can be optimized by implementations.
>
> All the new methods which produce lazy / functional views are on Stream.
>   So you can do
>
>    list.stream().sorted()
>
> to produce a new sorted stream.  To avoid making things more confusing,
> we followed the guideline of adding in-place mutative methods to the
> concrete collections, and adding functional / lazy methods to Stream,
> rather than mixing.

yes, only the problem is, that if we follow that rationale then we have 
to remove dozens of our additions plus, the non-mutating versions would 
not be available on a jvm before 8. Sadly we cannot strictly follow that

> BTW, adding stuff to Iterable is dangerous, as you've seen.  And you
> wouldn't even need default methods for that to happen; if we'd not done
> default methods at all, but added this sort method to ArrayList, you'd
> have the exact same conflict.

sure. That is always a danger. I don't say it is wrong to have it there, 
just wanted to know the background a bit more. On any interface there is 
a danger like that. Before the method was on List... that would have 
been an even worse conflict

> This worked as long as those JDK guys were asleep at the switch, and
> never updated the libraries.  But those days are over!
>
> I think you've got a few choices here:
>   - update your libraries
>   - modify your compiler to resolve these sorts of conflicts.
>
> For example, now that List has a conflict between
>
>    void sort(Comparator)
> and
>    List sort(Comparator)
>
> you could use target-typing in your method overload selection to pick
> one of these, rather than reporting a conflict.

you are forgetting that even though we also provide now a static 
compiler for a subset of Groovy, Groovy is basically a dynamic language. 
The chance, that there is no target type is high and runtime method 
selection does not even have that information.

> As a general rule, adding stuff to Iterable is probably going to cause
> ongoing pain.  Use with care.

Iterable, List, Collection, Map, CharSequence, Enumeration, Set, 
SortedSet, SortedMap, Iterable

That's about the interfaces we enhance.. Besides Enumeration all of them 
are dangerous I would assume.

bye Jochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org



More information about the lambda-dev mailing list