New Collections interface - Sized
Hi all, While a discussion on ReversibleCollection is going on, I'd like to raise the interface I've always found most missing from the framework - Sized public interface Sized { int size(); default boolean isEmpty() { return size() == 0; } default boolean isNotEmpty() { return !isEmpty(); } } This would be applied to Collection and Map, providing a missing unification. Anything else that has a size could also be retrofitted, such as String. Ideally arrays too, but that could come later. Note that Iterable would not implement it. WDYT? Stephen
This has come up before. For example, during an early iteration of the Stream design, before parallelism entered the picture. The first scrawled-on-a-napkin prototype for streams was based on Iterator, and it took about a minute to realize that we could do a much better job if we had a slightly broader interface to work with, essentially Iterator+Sized. When you pull on this string, you end up with a lot of new interfaces, such as SizedIterator, SizedIterable, etc, in part because ... we have no intersection types. Having lots of fine-grained interfaces for "has X" and "has Y" is nice from a "bucket of lego bricks" library-design perspective, but when the user goes to express "I need an aggregate that has sizes, iterators, and encounter order", you end up with code like: <T, X extends Iterable<T>&Sized> void foo(X x) { ... } and then you run into the wall of "but I can only use intersection types in these places in the language." The idiom of having fine-grained mix-in-ish interfaces really wants a language with intersection types. Additionally, I am having a hard time imagining how Sized would be usable by a client; no method will *take* a Sized (it's just not broad enough), and I can't immediately imagine what would even *return* a Sized. If the type is not suitable for use by clients, then it serves only to organize the library itself, and that's a weaker motivation. Is there a compelling example of where this would be used by clients? On 4/23/2021 5:23 AM, Stephen Colebourne wrote:
Hi all, While a discussion on ReversibleCollection is going on, I'd like to raise the interface I've always found most missing from the framework - Sized
public interface Sized { int size(); default boolean isEmpty() { return size() == 0; } default boolean isNotEmpty() { return !isEmpty(); } }
This would be applied to Collection and Map, providing a missing unification. Anything else that has a size could also be retrofitted, such as String. Ideally arrays too, but that could come later. Note that Iterable would not implement it.
WDYT?
Stephen
On Fri, 23 Apr 2021 at 17:08, Brian Goetz <brian.goetz@oracle.com> wrote:
This has come up before. For example, during an early iteration of the Stream design, before parallelism entered the picture. The first scrawled-on-a-napkin prototype for streams was based on Iterator, and it took about a minute to realize that we could do a much better job if we had a slightly broader interface to work with, essentially Iterator+Sized.
When you pull on this string, you end up with a lot of new interfaces, such as SizedIterator, SizedIterable, etc, in part because ... we have no intersection types. Having lots of fine-grained interfaces for "has X" and "has Y" is nice from a "bucket of lego bricks" library-design perspective, but when the user goes to express "I need an aggregate that has sizes, iterators, and encounter order", you end up with code like:
<T, X extends Iterable<T>&Sized> void foo(X x) { ... }
and then you run into the wall of "but I can only use intersection types in these places in the language." The idiom of having fine-grained mix-in-ish interfaces really wants a language with intersection types.
Additionally, I am having a hard time imagining how Sized would be usable by a client; no method will *take* a Sized (it's just not broad enough), and I can't immediately imagine what would even *return* a Sized. If the type is not suitable for use by clients, then it serves only to organize the library itself, and that's a weaker motivation.
Is there a compelling example of where this would be used by clients?
Here are some examples: https://stackoverflow.com/questions/10988634/java-global-isempty-method https://github.com/OpenGamma/Strata/blob/main/modules/collect/src/main/java/... ie. the ability to spot an "empty" object, or ensure input is non-empty. Use cases are generally in low-level/framework code like this, where the actual input data type is not known. Stephen
Is there a compelling example of where this would be used by clients? Here are some examples: https://stackoverflow.com/questions/10988634/java-global-isempty-method Without passing judgment on the sort of dynamically typed programs that need a method like this, or wondering what monstrosities such code uses to actually _get_ the data out of this weird ad-hoc union, note that this code becomes dramatically simpler with pattern matching:
return switch (c) { case null -> true; case CharSequence cs -> cs.length() == 0; case Collection c -> c.isEmpty(); case Object[] os -> os.length == 0; default -> { weird reflective thingy } } Note also that a Sized abstraction only addresses two of these five cases -- CharSequence and Collection. The others would still require such ad-hoc treatment. And while it may seem like I have pattern matching on the brain, there's a point to bringing up pattern matching -- which is that real code often ends up dealing with ad-hoc unions, and a linguistic mechanism for abstracting computations over ad-hoc unions is often a better solution if you find yourself in ad-hoc land than trying to partially unify it. But again, if you are treating these things as containers, then a Sized doesn't get you very far, because if you conclude the thing isn't empty, you're going to want to get stuff out, and Sized has no methods for that. So presumably there's some companion to Sized for accessing elements by index: interface HasStuff<T> extends Sized { T get(int index); } And note that in order for HasStuff to be useful, it has to extend Sized, because, no intersection types. Which suggests Sized is not the abstraction you are looking for. And again, pattern matching: Object getElement(Object thingWithStuff, int index) { return switch (thingWithStuff) { case null -> null; case Object[] os -> os[index]; case Collection<?> c -> c.get(index); ... more if you can think of them ... };
On Fri, 23 Apr 2021 at 23:07, Brian Goetz <brian.goetz@oracle.com> wrote:
Is there a compelling example of where this would be used by clients? Here are some examples: https://stackoverflow.com/questions/10988634/java-global-isempty-method Without passing judgment on the sort of dynamically typed programs that need a method like this
The other example is better as it benefits from declaring an API that only accepts instances of `Sized` and does not need to get the contents.
But again, if you are treating these things as containers, then a Sized doesn't get you very far, because if you conclude the thing isn't empty, you're going to want to get stuff out, and Sized has no methods for that. So presumably there's some companion to Sized for accessing elements by index:
interface HasStuff<T> extends Sized { T get(int index); }
I don't think there has to be. the more useful interface would be this one, but to date there has been strong resistance in unifying the Collection and Map interfaces: interface Stuff<T> extends Sized { int size(); int isEmpty(); int isNotEmpty(); Iterator<t> iterator(); } Stephen
----- Mail original -----
De: "Stephen Colebourne" <scolebourne@joda.org> À: "core-libs-dev" <core-libs-dev@openjdk.java.net> Envoyé: Samedi 24 Avril 2021 00:14:51 Objet: Re: New Collections interface - Sized
On Fri, 23 Apr 2021 at 23:07, Brian Goetz <brian.goetz@oracle.com> wrote:
Is there a compelling example of where this would be used by clients? Here are some examples: https://stackoverflow.com/questions/10988634/java-global-isempty-method Without passing judgment on the sort of dynamically typed programs that need a method like this
The other example is better as it benefits from declaring an API that only accepts instances of `Sized` and does not need to get the contents.
But again, if you are treating these things as containers, then a Sized doesn't get you very far, because if you conclude the thing isn't empty, you're going to want to get stuff out, and Sized has no methods for that. So presumably there's some companion to Sized for accessing elements by index:
interface HasStuff<T> extends Sized { T get(int index); }
I don't think there has to be. the more useful interface would be this one, but to date there has been strong resistance in unifying the Collection and Map interfaces:
interface Stuff<T> extends Sized { int size(); int isEmpty(); int isNotEmpty(); Iterator<t> iterator(); }
This is basically Spliterator, an iterator + a size, with the iterator is "push" instead of "pull" because it's more efficient. In details a Spliterator is either - an Iterable (with no SIZED characteristic) - an Iterable + size (if SIZED and estimateSize() != Long.MAX_VALUE) - an Iterable + comparator (if SORTED and comparator != null) - an Iterable + split (if trySplit != null) and all combinations of the above.
Stephen
Rémi
This is basically Spliterator, an iterator + a size, with the iterator is "push" instead of "pull" because it's more efficient.
In details a Spliterator is either - an Iterable (with no SIZED characteristic) - an Iterable + size (if SIZED and estimateSize() != Long.MAX_VALUE) - an Iterable + comparator (if SORTED and comparator != null) - an Iterable + split (if trySplit != null)
and all combinations of the above.
So, you're asking for Spliterable<T>, no? :)
----- Mail original -----
De: "Brian Goetz" <brian.goetz@oracle.com> À: "Remi Forax" <forax@univ-mlv.fr>, "Stephen Colebourne" <scolebourne@joda.org> Cc: "core-libs-dev" <core-libs-dev@openjdk.java.net> Envoyé: Samedi 24 Avril 2021 00:40:54 Objet: Re: New Collections interface - Sized
This is basically Spliterator, an iterator + a size, with the iterator is "push" instead of "pull" because it's more efficient.
In details a Spliterator is either - an Iterable (with no SIZED characteristic) - an Iterable + size (if SIZED and estimateSize() != Long.MAX_VALUE) - an Iterable + comparator (if SORTED and comparator != null) - an Iterable + split (if trySplit != null)
and all combinations of the above.
oops, i've written Iterable instead of Iterator.
So, you're asking for Spliterable<T>, no? :)
a Supplier<Spliterator<T>> is a Spliterable<T>, as in StreamSupport.stream() [1]. Rémi [1] https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/strea...)
----- Mail original -----
De: "Stephen Colebourne" <scolebourne@joda.org> À: "core-libs-dev" <core-libs-dev@openjdk.java.net> Envoyé: Vendredi 23 Avril 2021 11:23:03 Objet: New Collections interface - Sized
Hi all, While a discussion on ReversibleCollection is going on, I'd like to raise the interface I've always found most missing from the framework - Sized
public interface Sized { int size(); default boolean isEmpty() { return size() == 0; } default boolean isNotEmpty() { return !isEmpty(); } }
This would be applied to Collection and Map, providing a missing unification. Anything else that has a size could also be retrofitted, such as String. Ideally arrays too, but that could come later. Note that Iterable would not implement it.
WDYT?
There are 3 ways to have instances of different classes to have a common behavior in Java, - either thy implement a common super-type - or you use a structural type conversion (a method ref on an instance) here: Sized sized = list::size; - or you use pattern matching (or a cascade of if/else if you are like the old fashion) int size(Object o) { return switch(o) { case List<?> list -> list.size(); case Object[] array -> array.length(); case String s -> s.length(); default -> throw ... }; } The advantage of pattern matching is that it does not have a global impact, out of where you want to use it, by example, here, you can use s.length() instead of s.codepoints().count() without having to think what the default size of a String means for all program that can be written.
Stephen
Rémi
participants (4)
-
Brian Goetz
-
forax＠univ-mlv.fr
-
Remi Forax
-
Stephen Colebourne