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

Re: Ozone object identity...

It's fun to work on a global scale. The time difference make the
conversion on this list quiet interesting.

Anyway, I replied to Ola email with a possible implementation using
Object and Interface. See the other thread. 

However, the String based identity implementation may be more compact
and deliver the same result. So, here we go again. ;)

> We need a way to determine if to object are identical. 
> Period. Today this can be done via OzoneProxy.isSame().
> I agree that this is not a good solution since
> we need something to use as key in hastables and something
> that we can store and use later to get an proxy for the
> corresponding object.
>
> All this has to do with the identity of the object. And it
> is best handled via an Java object that represents the
> identity via proper implementation of hashCode(), equals()
> (and, if possible) the == operator. I agree on this too,
> now ;)
> 
> The 'implementation' of the identity object could be String
> because then we support the '==' operator, right? Okay. 
> (I will comment on the format of this string later)
> 

String is a simple solution. It give the same properies we needed as
object based implementation plus the side benefit of == operator using
String#inter();

However, I kind of lead toward a object based implementation of identity
now because the lack of hashCode() and inter() on the Waba VM we are
using for the small device. 

Defining our own interface will give us more control while dealing with
Java VM variant.

Anyway, if we decide to go with String based implementation, I will hack
Waba to support hashCode and inter. Love to be able to use '==' ;)

> > I need to hack up a quick demo for Waba and Ozone this week. I will
> > modify my local copy of Ozone to experiment with the idea of of using
> > String for the identity type and add only two methods to OzoneRemote:
> 
> OzoneRemote was meant as a tagging interface only. Adding methods to it means
> that we have them on _both sides, database and proxy. So OzoneCOmpatible and
> OzoneObject would have to provide implementations for it.
> 
> The straight forward way is to add it to OzoneProxy but then we need an
> additional cast...
> 

I think adding it to OzoneProxy is a better idea. If we are going for
String based implementation, the identity() method should be final and
programmers shouldn't be able to play with it.

> > public String identity();
> we could have Object as return type without breaking anything, right. If this
> is true, then I would like to return Object.
> 
> > public boolean isSame(Object obj);
> 
> Hm....??? we did all this to get rid of my isSame() and 
> now it is there again?
>
> We don't need this, right? o1.identity() == o2.identity() (or
> o1.identity().equals( o2.identity()) should be okay. (?)
> 

isSame() is just there as a convinient method. It's going to be
implemented as the following anyway. 

return (identity() == obj.identity());

If we are taking the minimalist approach to this problem, we should only
add a new method if adding it is the only way to archive the goal.

So, we have two possible implementation on the table now. 

1. OzoneObjectIdentity interface with:

public interface OzoneObjetIdentity {
    /**
     * must return hash code. The return value is 
     * for hashing purpose only. It doesn't carry 
     * any meaning.
     */
  public int hashCode();

    /**
     * this methods carry additonal semantics for
     * the object returning the identity in which
     * 
     * ozOne.identity().equals(ozTwo.identity())
     * IF AND ONLY IF
     * ozOne is identical to ozTwo
     */
  public boolean equals(Object);

    /**
     * toString will return a String value with the
     * following properties.
     *
     * ozOne.identity().toString().equals(ozTwo.identity().toString())
     * IF AND ONLY IF
     * ozOne is identical to ozTwo
     */
  public Strng toString();
}

OzoneRemote will be extended to have one additional method

public OzoneObjectIdentity identity();

OzoneInterface will be extended to have an additional method

public Object getObjectByIdentity(OzoneObjectIdentity identity);

2. A String based implementation:

OzoneRemote will be extended to have one additional method

public String identity();

OzoneInterface will be extended to have an additional method

public Object getObjectByIdentity(String identity);

The hashCode(), equals() and toString() methods of the identity string
will have same semantic as the OzoneObjectIdentity interface. In
addition to that, we can have extra semantic as

ozOne.identity() == ozTwo.identity()

IF AND ONLY IF

ozOne is identical to ozTwo.

This can be easily archive by using inter on String.

Put them side by side, String based implementation seems to have all the
advantage of OzoneObjectIdentity and it's simpler to implement. Other
than for those of us on VM that doesn't support intern and hashCode on
String! :(

----

Having the identity() on OzoneRemove may not be such a good idea. That
gives confusion. Maybe in OzoneObject.

Well... Let's pick our first implementation of identity and we will move
on to where to add identity() method.

David Li
DigitalSesame