The interfaces IdentityObject and ValueObject must die !

[Dan Smith]

On Jan 26, 2022, at 6:14 PM, John Rose <john.r.rose at oracle.com<mailto:john.r.rose at oracle.com>> wrote:


On 26 Jan 2022, at 16:55, Dan Smith wrote:

On Jan 26, 2022, at 4:55 PM, John Rose <john.r.rose at oracle.com<mailto:john.r.rose at oracle.com>> wrote:

Independently of that, for the specific case of Object

, having a query function Class.instanceKind

, which returns “NONE” for abstracts else “VALUE” or “IDENTITY”, would encode the same information we are looking at with those marker interfaces.

Right, so you're envisioning a move in which, rather than 'obj instanceof ValueObject', the dynamic test is 'obj.getClass().instanceKind() == VALUE'.

...

'Object.class.instanceKind()' must return NONE, just as Object.class must not implement either IdentityObject or ValueObject.

That last “must” is necessarily true, but the second-to-last “must” is not necessarily true. That’s my point here.

Okay, I understand—it's possible for library code to do whatever arbitrary things it wants, while 'instanceof' has specific, fixed behavior.

But... I don't really see how clients of this method would be comfortable with 'Object.class.instanceKind()' and 'Runnable.class.instanceKind()' returning different things. They've both got to be 'NONE', it seems to me. What does 'NONE' mean, if not "instances of this Class (and its subclasses) can be both value classes and identity classes"?

(I guess we could have two methods, one of which is called 'directInstanceKind'. But how likely would users be to use the right one, depending on which question they were trying to ask? And wouldn't those users smart enough to ask the right question be okay just testing for Object.class as a special case?)