The interfaces IdentityObject and ValueObject must die !

[John Rose]

On 26 Jan 2022, at 7:42, Dan Smith wrote:

> On Jan 26, 2022, at 2:18 AM, 
> forax at univ-mlv.fr<mailto:forax at univ-mlv.fr> wrote:
>
> In other words: I don't see a use case for distinguishing between 
> primitive and
> value classes with different interfaces.
>
> Primitive classes does not allow nulls and are tearable, following 
> your logic, there should be a subclass of ValueObject named 
> PrimitiveObject that reflects that semantics.
>
> But this isn't a property of the *class*, it's a property of the 
> *type*, as used at a particular use site. If you want to know whether 
> an array is flattened, the class of the component can't tell you.
>
> This is especially useful when you have an array of PrimitiveObject, 
> you know that a storing null in an array of PrimitiveObject will 
> always generate a NPE at runtime and that you may have to use either 
> the volatile semantics or a lock when you read/write values from/to 
> the array of PrimitiveObject.
>
> For examples,
>  public void m(PrimitiveObject[] array, int index) {
>    array[index] = null;  // can be a compile time error
>  }
>
> If we said
>
> class Point implements PrimitiveObject
>
> then it would be the case that
>
> Point.ref[] <: PrimitiveObject[]
>
> and so PrimitiveObject[] wouldn't mean what you want it to mean.
>
> We could make a special rule that says primitive types are subtypes of 
> a special interface, even though their class does not implement that 
> interface. But that doesn't really work, either—primitive types are 
> monomorphic. If you've got a variable with an interface type, you've 
> got a reference.
>
> We could also make a special rule that says arrays of primitive types 
> implement an interface PrimitiveArray. More generally, we've 
> considered enhancements to arrays where there are different 
> implementations provided by different classes. That seems plausible, 
> but it's orthogonal to the IdentityObject/ValueObject feature.
>
> Meanwhile, I'd suggest writing the method like this, using universal 
> generics:
>
> <T>  public void m(T[] array, int index) {
>    array[index] = null;  // null warning
>  }
>
> An impossible type, it's a type that can be declared but no class will 
> ever match.
>
> Examples of impossible types, at declaration site
>  interface I extends ValueObject {}
>  interface J extends IdentityObject {}
>  <T extends I & J> void foo() { }
>
> It would definitely be illegal to declare a class that extends I and 
> J. Our rules about well-formedness for bounds have always been 
> sketchy, but potentially that would be a malformed type variable.
>
> Abandoning the property entirely would be a bigger deal.
>
> If we do not use interfaces, the runtime class of java.lang.Object can 
> be Object, being an identity class or not is a just a bit in the 
> reified class, not a compile time property, there is contamination by 
> inheritance.
>
> Object can't be an identity class, at compile time or run time, 
> because some subclasses of Object are value classes.
>
> What you'd need is a property of individual *objects*, not represented 
> at all with the class. Theoretically possible, but like I said, a 
> pretty big disruption to our current model.
>
> For me, it's like opening the door of your house to an elephant 
> because it has a nice hat and saying you will fix that with 
> scotch-tape each time it touches something.
>
> Ha. This sounds like maybe there's a French idiom involved, but anyway 
> we should try to get John to add this to his repertoire of analogies.