251–260 of 358 posts
Earlier quoted context omitted.
A sealed class ought to have no methods, so it is plain old data. Then there's no purpose to overriding it.
I think you're thinking of `record` classes? Sealed classes are about constraining inheriting or implementing to only approved types - using sealed is pointless without overriding of some kind. Unlike in some other languages, where sealed is closer to java's final classes, i.e. stopping inheritance.
Earlier quoted context omitted.
This is a fair criticism. Java Instant should be the standard, and anything that doesn’t use it as its base should be deprecated. I have to support older JDKs, so I don’t know. The article starts with Java 9, and Instant was included with 8, so it is not a fault of the article.
I’ll gladly grant that the mutable date types of pre-jdk8 Java were ugly APIs, but you’re still missing my point here: the LocalDate class was added in the same release as Instant was—it’s not a worse Instant, it’s solving a different problem.
If you want something like a birthday, you’re already making assumptions about the beginning and end of that day. Ask a 21-year old from Australia about getting into USA bars on their birthday. It’s a system-specific decision on how to handle those things. Probably more relevant to finance, but the underlying principle is the same: dates without timestamps are ultimately derived from or interpreted with dates with timestamps, and hiding that fact too early in an API (like LocalDate might do) is a bad abstraction.
Earlier quoted context omitted.
Android is based on the JVM, it will never switch to Flutter (and an aggravating factor is that Dart is an inferior version of Kotlin).
Java is an Android's curse. Just compare how completely native iOS and iPadOS beat it in terms of speed and power saving. I hope they will get rid of the Java remnants completely and focus on the native toolchain, frameworks, system libraries.
Am I the only one who's seeing "sealed" classes as an unfortunate development? I can't count how many times I had to resolve to using PowerMock and hacking bytecode just to mock something in one of the libraries I use because it's ingenious author "final"-ed the whole API surface of the library (and bits of the implementation usually). Now this gives even greater tool to people who love to lock everything up and thin…
Earlier quoted context omitted.
What would do notation add to Java?
There are lots of places where it can help, but to give one example consider the Java 8 Optional type. It’s great for avoiding nulls, but you get excessive nesting with many isPresent checks. Do notation can fix this. The language even provides a bind function, but no reasonable way to use it!
I used to really love Java, it was my second "real" programming language after C/C++, and GC, type safety, and object orientation really changed the way I thought. I also learned almost all I knew about high-performance VMs (up to 2013) in the context of JVMs. But these days it seems like Java is engaged in one long apology for the "everything is an object" mindset it started out with. It both took it too far and not…
Does java have a decent story on value types now e.g can I make an ArrayList and trust that it’s one array of longs on the heap and not an array of pointers to Longs? This was what made me ragequit Java 10 years ago.
Not yet. You can track Project Valhalla [0], the incubator for value/inline types in OpenJDK. But I don't get the sense it's landing particularly soon. https://openjdk.java.net/projects/valhalla/
Am I the only one who's seeing "sealed" classes as an unfortunate development? I can't count how many times I had to resolve to using PowerMock and hacking bytecode just to mock something in one of the libraries I use because it's ingenious author "final"-ed the whole API surface of the library (and bits of the implementation usually). Now this gives even greater tool to people who love to lock everything up and thin…
Without sealed classes it's impossible to enforce most interesting invariants. If anything the other way is a mistake.
From https://news.ycombinator.com/item?id=16952659 (and all the related links to that comment and the original article - The Impoliteness of Overriding Methods)
Earlier quoted context omitted.
Except that having the type info is really, really useful at the call site. I know the IDE is able to infer it and display it but it's still a pain to see all the vars during a code review in a browser.
Agree, it's a straight up reduction in code readability for all future maintainers so a single original developer can avoid doing a thing their IDE probably would do for them automatically. (I use "introduce variable" to create most variables automatically of the correct type). Yes I know the IDE can also reveal what type a var is, but you generally read code in lots of places that aren't IDE enabled. It also adds mo…
Earlier quoted context omitted.
I think you're thinking of `record` classes? Sealed classes are about constraining inheriting or implementing to only approved types - using sealed is pointless without overriding of some kind. Unlike in some other languages, where sealed is closer to java's final classes, i.e. stopping inheritance.
If they are like Scala's I do mean sealed.