3 ms·

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 valu

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.

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.