I mean, how are you going to use it? Something like this?
Point p = getPoint();
if (p instanceof Point(int x, int y)) {
System.out.println(x+y);
}
This type of pattern matching is mostly useful when you have some T and a few cases, there is also a switch/case equivalent for when you've got a lot of them.
Maybe we'll see some syntax for deconstructing values directly into variables, a la Python in the future.
You can then use pattern matching to switch on instances of those subclasses while destructuring objects to access attributes at the same time. Kind of like enums and pattern matching in Rust.
In your example there is no reason to use `instanceof` with `p`, you already know what it is.
Sure, but in Java the standard handling of that is polymorphism. instanceof has been so far a bit of an antipattern, breaking out of the OOP model.
> In your example there is no reason to use `instanceof` with `p`, you already know what it is.
That's my point. This seems like a very limited version of destructuring if you can use it only when you don't know the type. Like in JavaScript you'd routinely write something like:
const {x, y} = getPoint();A more practical (though not necessarily realistic) example might be:
sealed interface List<T> permits Cons<T>, None<T> {
record Cons<T>(T head, List<T> tail) {}
record None<T>() {}
}
// some function only wanting the first elem of a list
switch (List<T> list) {
case Cons<>(T head, var tail) -> // do something
default -> {}
}
I think that's deliberate, Java is moving towards the modern programming zeitgeist that doesn't really care about strict adherence to the OOP model. This is a feature that comes from languages that don't adhere to Java's OOP principles.
I didn't downvote you, by the way. Don't know why that happened.
This, along with the underscore, and even the sequence type, shows that the language designers are well aware of what Scala does, and are picking and choosing which things to bring in without risking exposing Java devs to the traditional monad salads that you see in many a Scala codebase.
But yeah, of course the design team knows about features from Scala, they are probably one of the most competent people on the Earth when it comes to PLs, and are literal CS giants.
the problem is that Java not modern language, but carrying all legacy features from last 20 years, so having all legacy features + new modern creative ideas make Java very complex.
Overwhelmingly, I see complaints that java has been too simple compared to virtually all other languages. I agree that cognitive load is important. However, it feels really strange to me to suggest that java has reached the complexity of other similar languages. What am I missing?
- using DataInputStream
- using Scanner
- using Reader
- using Files.readLines
and they all suck.
I think they all connected, for example with added lambdas they also added streams, so collections library now allows to do the same thing using old iterators or new streams APIs, and somehow those APIs are not compatible, it is not easy to produce stream from iterator.
which I never seen anyone uses and it makes everything more complicated
they probably should've have some ParallelStream interface
core ecosystem, e.g. apache commons will add several more ways.
Java’s standard library is one of the best stdlibs out there.
programmers in 95% cases want something like following to read lines from text file:
for s in open('file.txt'): print(s)
Java has 5 different io APIs and no one provides such construct, you need to stack various verbose abstractions to just read text file.
How it is the best? Ergonomics and brain load is very bad.
string[] lines = ReadFile("path", "filename");
- it will produce OOM if file is very large
- iterating array is usually verbose in many of languages (at least in Java)
- not sure why you would want to have path and filename as separate params
In Java, it would be more ergonomical if they add something like following:
Iterable<String> Files.readAllLines(String fileName);
Also, I really don’t understand your last example - that’s literally available in java returning a List of lines. If you add a .stream().collect(joining(“\n”)), you get the whole string in one go.
I think in python it will lazely iterate through the file, and not load everything at once
> Java’s List is much more ergonomic that arrays.
right, but commenter above proposed array..
> that’s literally available in java returning a List of lines.
current API has two issues:
- OOM if file is large
- it takes Path instance which you need to construct and not "String file" parameter, thus hit on ergonomics
- it will produce OOM if file is very large
- not sure why you would want to have path and filename as separate params
Iterable<String> Files.readAllLines(String fileName);
I think in python it will lazely iterate through the file,
this is possible solution, still it doesn't allow to iterate lines one by one and handle large files
> Throws path not found. Throws file not found.
I think it is some very niche use cases when you need to distinguish between these cases. From another hand there are many places in the code which operate absolute file paths already, and you force them to split path, which is cumbersome. At least two alternative APIs probably are justified to have.
> Fastest was suck each one into memory and call split.
I really don't think pre-splitting is any kind of performance bottleneck, it is likely 1% of performance compared to all IO stack and subsequent string/objects memory management.
IMO it's a significant syntactical improvement, as it considerably reduces boilerplate assignments.