1. If your class doesn't do Identity Things, make it a value class. The VM can do smarter things now.

Which also makes your class safer too!

2. `==` isn't really an Identity Thing: it will just continue to mean "observably identical*" as it always has. System.hashCode() remains defined in terms of `==`. But actual identity dependence will fail (when feasible, at compile time).

Some readers might retort that the cost of this is `==` went from ultra-super-cheap to maybe-but-who-knows.  We might counter-retort that such micro-performance concerns are usually a distraction.

3. Any type based on that class can be marked as nullable `?` or non-null `!`. Conceptually (if not literally), `Foo!` is a subtype of `Foo?`.

Where by "conceptually" you are appealing to "is-a".

4. Nullness enforcement is "best-effort" and better than nothing. *If* you want the gory details of what's enforced you can dig into them. There's still room for third-party nullness analysis tools to help.

5. If a value class has a do-nothing constructor, and you're fine with non-null variables of that type being initialized to that value, add `implicit` to the constructor. The VM can do more smarter things now.

6. Consider adding `non-atomic` to the class; the VM can do even morer smarter things now. The downside is that racy code (already risky) might fail in worse ways; you decide if that worries you or not.

And specifically, if your class has cross-field invariants, it should worry you.

7. The above holds for the 8 primitive types too; yes, they are still special, but mostly in /additional/ ways, rather than exceptions to the usual rules. `int` and `Integer!` are now nearly synonymous.

And we can finally all retire the term "primitive class" now at last. :-)

Praise be.

While that list is meant to have asterisks and just be "good enough for most people most of the time", it might need some important corrections nevertheless, so, I'm glad to hear them.


* yes float/double are weird

--
Kevin Bourrillion | Java/Kotlin Ecosystem Team | Google, Inc. |[email protected]

Reply via email to