[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ozone object identity...

What David seems to suggest is that every ozone object should be globally and eternally unique (GEU), and retrievable via a retrieval mechanism in Ozone that you feed with a identifier object. I believe this is good, and that it breaks my suggestion for using Object.

My suggestion was to use Object as the minimal interface for the identifier, so that the API wouldn't be locked to a particular identity class for all future.

In order to ensure global and eternal uniqueness (GEUness) one has to refine the contract for Object, so that the actual implementing class will produce that uniqueness, not only (as in the current contract for Object) unique within one VW instance.

I don't think an int value (as returned by Object#hashCode()) will suffice for GEUness. If it does, all we have to do is providing a tagging interface (like "OzoneObjectIdentifier") that says that the actual identifier object's hashCode() will produce GEU values.

My second proposal will be to state that the OzoneObjectIdentifier interface will provide a getKey() method that returns something GEU. This would still leave the mechanism for identity up to the implementor (allowing for different implementations), and the object would be serializable too. 

What type should getKey() return? It should be something primitive. If one can ensure GEU using long (which I doubt), let it return long. I know that byte[] will always work, and be generic enough. Any OzoneObjectIdentifier will in effect be a wrapper around the thing that getKey() returns.

I dislike David's String proposal. This will tie the concept of GEU Ozone objects to a particular GEU-mechanism, when we only need the GEUness. I believe that both serialized and externalized OzoneObjectIdentifier objects should be compatible between implementations.

But I believe that David's thoughts are good, but that it should be implemented as a bean that implements OzoneObjectIdentifier, and whose toString() method generates the String David proposes.

Another quarter's worth of thoughts...

/O