PrimitiveObject interface

[Gernot Neppert]

Hi Dan,

a while ago on this mailing list, there already was a discussion about 
the necessity of two complementary interfaces.

IIRC, consent was obtained that, since "IdentityObject" actually adds 
some capabilities to java.lang.Object - such as synchronization - a 
marker interface was warranted,

whereas primitive classes do not offer anything over plain 
java.lang.Object which could be exploited via an explicit interface.

Nevertheless, back to your propsal:

I dare challenge your assertion about "symmetry". If we had such an 
interface "PrimitiveObject" - in what contexts would that appear?

As you yourself wrote, it could by used as type-bounds for method 
arguments. Now, consider a generic method

<T extends PrimitiveObject> void foo(T arg) {

}

Once I pass an argument of a concrete primitive type to this method, it 
will be automatically submitted to the "reference-projection", since the 
argument is of an interface-type.

Question 1: is this even possible? I may have gotten this wrong, but to 
me the "reference-projection" implies that an object of the associated 
".ref" class will be passed, which would then not implement 
"PrimitiveObject" in the first place!

Question 2: the erased function "foo" has an argument of an 
interface-type, which is a good old-fashioned Java reference. Inside 
foo(), in what way would I be able to exploit the fact that arg was a 
primitve object originally?


Some further remarks:

> Certain abstract classes (e.g., those with fields) implicitly implement IdentityObject (this is not new)

What would happen if such an abstract class explicitly implements PrimitiveObject? Would the compiler be required to reject compilation?


> It's a (load-time?) error for a class or interface to extend both PrimitiveObject and IdentityObject

Would that be necessary? Given that a conforming compiler could never generate such a class, what potential danger would be averted by introducing such a load-time check?