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

Re: Ozone object identity...



On Mon, 30 Apr 2001, David Li wrote:
> I am back. Got side track to do some Waba hacking. Waba is a Java VM
> implementation for small device like Palm or Pocket PC. There will be
> some relevance with the object identity we are discussing here later on.
> 
> > > Using default equals and hashCode may not be such a good idea since
> > > there may be need in application to override those two methods.
> > 
> > On the other hand it's a very good idea since it allows to handle the
> > persistent object identity of ozone the same way as the identity of transient
> > objects. For transient objects you can easily determine if two object are the
> > same but you can _not_ access the pointer/id/reference/whatever-it-is-in-Java
> > directly. The proxies of ozone act the same way.
> > 
> 
> Well... This is getting philosophical but here we go. 

philosophical? maybe. but not waste!

> 
> According to the formalism of Object Oriented Programming, each object
> has identity, state and behavior. Identity is unique for each object. 
> 
> For Java transient objects, the identity is the "object pointer" and the
> equality of two object should be determined by the '==' operator. For
> example,
> 
> MyObject objOne = new MyObject();
> MyObject objTwo = new MyObject();
> 
> These are two objects with two unique identity. 
> 
> The equals() operator should mean equivlent. It means that two object
> have the same states. The following is a quote from the api doc of
> java.lang.Object.
> 
> "The equals method implements an equivalence relation"
> 
> Being "equals()" does not mean that two object are identical. It just
> mean the two object has the same state.
> 
> The hasCode() according to the api doc doesn't really imply anything on
> an object's identity or equivelance. It's simply, as implied by its
> name, a hashCode. We can have the following situation and it's perfectly
> legal.
> 
> objOne.hasCode() == objTwo.hasCode() ----> TRUE
> objOne.equals(objTwo)                ----> FALSE
> objOne == objTwo                     ----> FALSE

ok. What you are saying is: hashCode() + equals() does not make up the identity
of an object. I agree. But this wasn't the problem. The problem was that 1) we
wanted to use a proxy as a key in a hashtable and 2) we needed something that
we could store and find the corresponding object in the db later on.

Olas suggestion to return an object that properly implements hashCode() +
equals serves both 1) and 2) well.

Except that my idea of naming the method that return this object 'identity()'
does not really correspond to the idea of this method. This breaks my own ideas
since, as I stated from the beginning, I do not want to give the programmer an
ID or identity or something like that.

> 
> For transient Java object, we do have access its object pointer. The
> pointer being the one assigned to the object variable and the only
> operation available for us is ==. The default hasCode() of
> java.lang.Object is a native method and it retrive the memory address of
> the allocated object. In sense, this is the object id to the particular
> object.
> 
> If we can accept the above notion on object id, equals() and hasCode(),
> the current implementation of Ozone doesn't give an object its identity

This is true and perfectly intended. I just substituted '==' by isSame() for
persistent objects. The contract of hashCode() and equals() are the same for
transient and persistent object - that was the idea! (at the same time
time this lead to the mentioned problems when using proxies as (efficient) keys
in hashtables)

> and an identity is the most important value of an object in a OO world.

True but again, IMO the programmer does not need a way to directly access this
identity of a persistent object.

> 
> > Anyway, sometimes you have to change the behaviour of hashCode/equals, which
> > then breaks this model. What about a identityHashCode() method?
> > 
> > Also, David, what do you want to return from a getObjectIdentity() method? The
> > internal object ID? This would make client code depend on the internal
> > implementation! (the current 64bit number is one solution maybe we have to
> > change this for some reasons in the future)
> > 
> 
> My idea is to return a String repreenting the Object ID. My current
> thinking is to use an URI to represent the object id. This idea is
> largely influence by the RDF and Semantic Web
> (http://www.w3.org/2001/sw/). The idea is to make each ozone object
> universal on Internet.
> 
> The format of the URL will be roughly look like the following:
> 
> ozonedb:remote://ozone.d11e.com:3333/com.d11e.MyObject/1.0/1234/5678

Hmmm.... I don't like this. (read on!)

People will start interpreting this String and using it and depending their
code on the format of this string.

> 
> It's divided into the following parts:
> 
> 1. Server ID: ozonedb:remote://ozone.d11e.com:3333
> 
>   This is to locate the server on the Internet.
> 
> 2. Class name: com.d11e.MyObject
> 
>   The Class for the object.
> 
> 3. Class version: 1.0 
> 
>   The Class version to help correct marshall and unmarshall of an
> object. Maybe support schema evalution.
> 
> 4. Object version: 1234
> 
>   This is a version number that is updated each time an object state is
> updated. This will be a useful field for the ClientCacheDatabase
> implementation. 
> 
>   This is the link to the small device Java VM I talked about in the
> beginning of this mail. A cacheclient database is very important for
> handheld device, esepcially to support discontinuous operation on the
> object. Most handheld can't be always connected. Most of time, a
> handheld device is discounted from the net and are required to be
> operational with the data it has.
> 
>   Having a object version will help in conflict detection in this case.
> The proper resolution will probably come from work in distributed
> database. There are some ideas but not thing concrete. 
> 
> 5. Object identity: 5678
> 
>   Well... this is it! ;) It's the Object's id in the database. 
> 
> 6. The hashcode. We can probably adapt the URN for the id's hashCode. 
> 
> The ideas here are largely influenced by the following
> 
> I. Webizing existing systems:
> 
>   http://www.w3.org/DesignIssues/Webize.html
> 
> II. Universal Resource Identifiers -- Axioms of Web Architecture
> 
>   http://www.w3.org/DesignIssues/Axioms.html
> 
> III. Naming and Addressing: URIs, URLs, ...
> 
>   http://www.w3.org/Addressing/
> 
> > So, I would like to avoid to have a method that appears to return the object
> > ID of an object back to the client. This, IMO, leads to wrong designs. We
> > don't need this as Java doen't need pointers. The identityHashCode() in fact
> > does nothing else but people would not expect a getObjectByHash() method
> > somewhere in the ozone API because such a method does also not exist in the
> > Java model in general.
> > 
> > getObjectIdentity() / getObjectByIdentity() are wrong IMO and would break the
> > design of ozone.
> > 
> 
> With the above argument on identity and equivlance, I think it's proper
> to have methods that return object id to the client. 
I still don't see the need to give the programmer something that represents the
identity of an object. Something that properly implements hashCode() and
equals() is enough for all use cases that I can think of.

Anyway, maybe we decide to return your String, David but we should not
document the format of the string and voila!... we are there.

> We properly can't
> implement a discontinued connecting  client cache database without one.
> 
> I'd propose the following addition to an OzoneRemote interface:
> 
> public interface OzoneRemote {
>     public String getObjectIdentity();

We should consider to not name this getIdentity() but getKey() or something.
(yes I know, I proposed identiy() in the first place)

>     public String getObjectIdentityHash();
>     public boolean isSame(Object obj);
> }
> 
> Also, in the OzoneInterface, add
> 
>   public Object getObjectByIdentity(String objectIdentity);
> 
> David Li
> DigitalSesame


Falko
-- 
______________________________________________________________________
Falko Braeutigam                              mailto:falko@smb-tec.com
SMB GmbH                                        http://www.smb-tec.com