This is really interesting. I've worked and lived alongside Java since, like, becoming extremely proficient in AS3/ECMA5(ish) and understanding the low-level quirks of that VM, but I never dealt in Java.
What's funny to me is that by your description, AS3 started almost as dynamic as the objective mess you're describing, and somewhat correctly headed down a path of compile-time type safety along its trajectory, which kind of gave good guardrails for those of us who had to switch to a wild west nonsense of JavaScript tempered with some hints from typescript.
I wasn't aware that you could `==` two objects in Java and that it would, like, deconstruct them somehow and see if their contents matched rather than just telling you whether they referenced the same object. I'm not even sure if that is what you're saying, because that's wild and insane and it's the whole reason for observable classes in other languages (which are sort of hackish). But after so many years of like, figuring out the quickest ways to diff similar objects, relying on the VM to do it would feel like never the best solution to any given problem, and more of a footgun than a feature...?
`==` is reference identity in java and that is the problem. so you can't treat an arbitrary object as a value type because somewhere in the program `==` might be called on it.
I think there is some major misunderstanding here.
The point the OP was making is that a Sufficiently Smart Compiler should be able tell if a class is a reference class (and must be allocated on the heap and referenced by pointer) or a value class (that can be copied around and stored in-line in arrays or other classes).
Specifically, a class can only be a Value Class if two instances of this class are never compared using reference comparison, ==. If the program never uses this operation on two instances of this class, that means that the program would never be affected if copies are passed around instead of the original object being referenced around.
The GP was pointing out that this verification is not actually feasible, as it requires access to the entire source of the entire program, it can't be decided locally.
Comments
This is really interesting. I've worked and lived alongside Java since, like, becoming extremely proficient in AS3/ECMA5(ish) and understanding the low-level quirks of that VM, but I never dealt in Java.
What's funny to me is that by your description, AS3 started almost as dynamic as the objective mess you're describing, and somewhat correctly headed down a path of compile-time type safety along its trajectory, which kind of gave good guardrails for those of us who had to switch to a wild west nonsense of JavaScript tempered with some hints from typescript.
I wasn't aware that you could `==` two objects in Java and that it would, like, deconstruct them somehow and see if their contents matched rather than just telling you whether they referenced the same object. I'm not even sure if that is what you're saying, because that's wild and insane and it's the whole reason for observable classes in other languages (which are sort of hackish). But after so many years of like, figuring out the quickest ways to diff similar objects, relying on the VM to do it would feel like never the best solution to any given problem, and more of a footgun than a feature...?
`==` is reference identity in java and that is the problem. so you can't treat an arbitrary object as a value type because somewhere in the program `==` might be called on it.
I think there is some major misunderstanding here.
The point the OP was making is that a Sufficiently Smart Compiler should be able tell if a class is a reference class (and must be allocated on the heap and referenced by pointer) or a value class (that can be copied around and stored in-line in arrays or other classes).
Specifically, a class can only be a Value Class if two instances of this class are never compared using reference comparison, ==. If the program never uses this operation on two instances of this class, that means that the program would never be affected if copies are passed around instead of the original object being referenced around.
The GP was pointing out that this verification is not actually feasible, as it requires access to the entire source of the entire program, it can't be decided locally.