2. Substitutability
Remi: lambda examples use ==. None use == followed by .equals, in fact
none use .equals.
Karen: other searches have found 10-50% use == followed by .equals
Remi: Hard to find cases with static Object/Interface and dynamic
Lambda today
Code that knows what it is dealing with generally uses either `==` or
`.equals()` but not both.
Generic code (including dynamically typed code, like pre-generic
collections) generally use `==` followed by `.equals()`, but sometimes
just uses `.equals()` (which is OK). Just using `==` is, of course,
dangerous, unless you know that you are dealing with constrained
instances (enums, interned strings, etc.)
The historical route by which we got here is:
- In the interpreted days, `==` was a fast filter for `.equals()`,
since when crawling a list, most things are not equal to what you're
looking for;
- Because `==` was historically fast, it is harmless as a pre-check.
Now, method invocation got faster, and `==` is going to get slower, so
obviously the equilibrium will change.
Karen: Challenges:
component-wise substitutability
- primitives - usual check (floating point extra care)
- pojos - non-Object/Interface - reference comparison
- value type - static or dynamic (Object/Interface) - requires
recursive check
Concerns:
performance - due to lots of fields or depth or both
could get StackOverflowError from unbounded links
e.g. for a valid use case - tree-node
Is it appropriate for acmp to perform a substitutability check? It was
intended as a short circuit pretest to a longer test.
I am still preparing my armaments for this assault :)
3. Nullability
Editor’s note: LW2: QPoint; null-free reference to Point. LPoint;
nullable box for Point.
I would prefer to reframe this as "opting into protection against
uninitialized values".
