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