4 ms·

The "optional" write methods look like awful design choices. If my method needs a writable sequenced collection I have no way to express that. I just need to ho

The "optional" write methods look like awful design choices. If my method needs a writable sequenced collection I have no way to express that. I just need to hope that you give me one or you will get exceptions. Why not break it into two interfaces? One for immutable and one with the mutable operations so that this is naturally expressible and checked by the type system?

dtech 4y ago
It's how all Java collection interfaces work have worked since forever. They probably don't bother introducing new super-interfaces because Java code is never going to migrate from List etc.
- kevincox 4y ago
  But here we are, introducing new super-interfaces. Why not do it properly?
- masklinn 4y ago
  > It's how all Java collection interfaces work have worked since forever. And it’s been an issue since forever, and this is specifically introducing new super-interfaces, so why miss the opportunity again?
  - pjmlp 4y ago
    Because developers are lazy and most will never migrate unless forced to.
- dmitriid 4y ago
  1. It's been forever, and because of that: 2. People are never going to migrate from List, and so we: 3. Must do the same exact thing again and again, to ensure: 4. That people are never going to migrate from List
nlitened 4y ago
What if your method needs an empty collection, you'd have no way to express that. Or it needs a collection with even or odd number of elements depending on value of the first element. At some point you have to stop playing with types and start coding.
- mattgreenrocks 4y ago
  This is an odd comment on a JEP for introducing more super types. Parent comment is right: throwing an exception is surprising behavior and the interface’s design breaks the Liskov substitution principle.
- kevincox 4y ago
  You are right, but that is throwing the baby out with the bathwater. There is a limit to what can reasonably be expressed in a type system but that doesn't meant we should just give up. Moving a group of methods that just throw a NotImplementedError to a different interface so that you can talk about then seems fairly low effort and high value.
- nine_k 4y ago
  To statically analyze whether you receive an empty collection or not, you need dependent types, a thing which Java does not have, and will not have in foreseeable future. To tell mutable and immutable collections apart, you just need two separate interfaces, a feature available in Java for decades, and an approach widely and routinely used everywhere in the language.
  - d35007 4y ago
    > To tell mutable and immutable collections apart, you just need two separate interfaces, a feature available in Java for decades, and an approach widely and routinely used everywhere in the language. Part of the problem might be that Java's existing interfaces for collections don't have that split. `List`, `Set`, and `Map` already declare mutators, and they're used pervasively. On the other hand, the Java folks clearly recognize that mutability is the wrong default for modern programming languages, so why double down on the mistakes of the past? They might argue that it makes more sense to follow established patterns than it does to create new ones, because it creates less friction for Java developers.
jiehong 4y ago
This is discussed in the following section: > Add, put, and UnsupportedOperationException
pron 4y ago
Because when dealing with mutability, you usually want to specify which of two parties can mutate: none (immutable collection), only the producer (read-only interface), only the consumer (transfer of ownership), or both (mutable collection). E.g. a read-only interface does not tell a receiver whether or not it is safe to store in a field. So to do it "properly" either you multiply the number of interfaces by four, or complicate the type system to track ownership. Either way, the price for that feature is high, and it's not yet clear at this point whether the benefits are worth it. Not every solution to every problem is worth it. Sometimes it's best to do nothing and spend the time on more worthwhile things, and perhaps a cheaper solution would present itself in the future.
stickfigure 4y ago
IIRC Ceylon did this. It was very cool, especially with union and intersection types. They didn't use the standard java collection interfaces though. Too bad the language didn't take off.
- isbvhodnvemrwvn 4y ago
  Scala had a separate hierarchy of collections as well IIRC (and their entire collection thing seemed like a much better design than what Java did, admittedly with years of learning from Java's mistakes)
mormegil 4y ago
This is how it already has been in Java. It’s explained in an ancient Design FAQ document: https://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html#a1 https://docs.oracle.com/javase/8/docs/technotes/guides/colle...
vbezhenar 4y ago
I guess that's another change which is much more hard to implement properly. I'd like to see it done though.

dtech 4y ago

It's how all Java collection interfaces work have worked since forever. They probably don't bother introducing new super-interfaces because Java code is never going to migrate from List etc.

kevincox 4y ago
But here we are, introducing new super-interfaces. Why not do it properly?
masklinn 4y ago
> It's how all Java collection interfaces work have worked since forever. And it’s been an issue since forever, and this is specifically introducing new super-interfaces, so why miss the opportunity again?
- pjmlp 4y ago
  Because developers are lazy and most will never migrate unless forced to.
dmitriid 4y ago
1. It's been forever, and because of that: 2. People are never going to migrate from List, and so we: 3. Must do the same exact thing again and again, to ensure: 4. That people are never going to migrate from List

nlitened 4y ago

What if your method needs an empty collection, you'd have no way to express that. Or it needs a collection with even or odd number of elements depending on value of the first element. At some point you have to stop playing with types and start coding.

mattgreenrocks 4y ago
This is an odd comment on a JEP for introducing more super types. Parent comment is right: throwing an exception is surprising behavior and the interface’s design breaks the Liskov substitution principle.
kevincox 4y ago
You are right, but that is throwing the baby out with the bathwater. There is a limit to what can reasonably be expressed in a type system but that doesn't meant we should just give up. Moving a group of methods that just throw a NotImplementedError to a different interface so that you can talk about then seems fairly low effort and high value.
nine_k 4y ago
To statically analyze whether you receive an empty collection or not, you need dependent types, a thing which Java does not have, and will not have in foreseeable future. To tell mutable and immutable collections apart, you just need two separate interfaces, a feature available in Java for decades, and an approach widely and routinely used everywhere in the language.
- d35007 4y ago
  > To tell mutable and immutable collections apart, you just need two separate interfaces, a feature available in Java for decades, and an approach widely and routinely used everywhere in the language. Part of the problem might be that Java's existing interfaces for collections don't have that split. `List`, `Set`, and `Map` already declare mutators, and they're used pervasively. On the other hand, the Java folks clearly recognize that mutability is the wrong default for modern programming languages, so why double down on the mistakes of the past? They might argue that it makes more sense to follow established patterns than it does to create new ones, because it creates less friction for Java developers.

jiehong 4y ago

This is discussed in the following section: > Add, put, and UnsupportedOperationException

pron 4y ago

Because when dealing with mutability, you usually want to specify which of two parties can mutate: none (immutable collection), only the producer (read-only interface), only the consumer (transfer of ownership), or both (mutable collection). E.g. a read-only interface does not tell a receiver whether or not it is safe to store in a field. So to do it "properly" either you multiply the number of interfaces by four, or complicate the type system to track ownership. Either way, the price for that feature is high, and it's not yet clear at this point whether the benefits are worth it. Not every solution to every problem is worth it. Sometimes it's best to do nothing and spend the time on more worthwhile things, and perhaps a cheaper solution would present itself in the future.

stickfigure 4y ago

IIRC Ceylon did this. It was very cool, especially with union and intersection types. They didn't use the standard java collection interfaces though. Too bad the language didn't take off.

isbvhodnvemrwvn 4y ago
Scala had a separate hierarchy of collections as well IIRC (and their entire collection thing seemed like a much better design than what Java did, admittedly with years of learning from Java's mistakes)

mormegil 4y ago

This is how it already has been in Java. It’s explained in an ancient Design FAQ document: https://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html#a1 https://docs.oracle.com/javase/8/docs/technotes/guides/colle...

vbezhenar 4y ago

I guess that's another change which is much more hard to implement properly. I'd like to see it done though.