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

Re: Hacking

Hi Falko,
Thanks for responding. I would like to help with the development so I'm
looking for opportunities or "hot spots" in the code. Some of the places
I look first is the developer API. The first thing I saw is the method
that creates objects in the client API has a String sig parameter which
I didn't think was necessary. I also look at extremely long call chains,
methods in objects that don't seem to fit ...

I like to find areas for improvement to help learn the code base. I
might also like to write documentation as well. So hopefully this
explains my methods.

Falko Braeutigam wrote:
> 
> On Fri, 18 May 2001, Eric Richardson wrote:
> > Hi,
> > I finally got a chance to look at the source code. I was particularly
> > interested in the ObjectId discussion we were having and the
> > ExternalDatabase.createObject( with the sig argument).
> >
> > I followed the code about to see where this originated and found a few
> > interesting things. I found DxObject.c which looks like it may have been
> > left over from the 1.0.2 days before there was full reflection?
> yes
> 
> > I
> > couldn't seem to find the createTarget() in the ClassicObjectContainer
> the classicStore is not supported. don't woryy about that code.
> 
> > implementation but found the invokeTarget(with sig) code for method
> > invocation and if sig is null it creates the method with the parameter
> > types.
> which is dangerous because the types of the actual params doesn't need to be
> exactly the same types as of the formal params.

Should we remove the code - you seem to agree that it is not desirable.

As far as I know it still has to follow the language standard so if you
could call the method directly and the rules for call by reflection are
the same. The ozone code uses the Class.getMethod(String name, Class[]
parameterTypes)/getConstructor(Class[] parameterTypes) which should
really return the correct Method or constructor. I played with a
reflection code test and found it worked as I expected. Of course the
client has to package ints with Integer etc. to place the arguments in
an Object[] for the invocation.

> 
> The container has to have the responsibility to create new objects. Thus the
> createTarget method, which is called by Transaction.createObject().
> 
> It's important for the createTarget() method to know the _exact_ types of the
> _formal_ params of the method in order to be able to always find the right
> method to invoke.
> 
> Why do you want to eliminate the createTarget() method?

Only want to remove the "String sig" parameter from the method because
this doesn't seem necessary.

> 
> >
> > About the ObjectId discussion. Were you think of internalizing the OID
> > into the actually OzoneObject or leaving it in the container?
> ???

The code outside the container creates the persistent object and the
ObjectId and passes these to the container. We were discussing whether
the OzoneProxy would have a ObjectIdentity getObjectIdentity() and
method boolean isIdentical(OzoneRemote) methods(like the isSame method
on the OzoneObject) and then the hashCode and equals methods on the
ObjectIdentity class would be the ones that were guaranteed to have the
correct semantics.

Couldn't the OzoneProxy and the OzoneObject both hold the object id and
share the same interface maybe thru OzoneRemote? Then (looking at
ClassicObjectContainer) the ObjectContainer could just get the
ObjectIdentity from the OzoneObject rather than holding it itself. This
seems more encpasulated with the exception of allowing the client to get
the id as mentioned above. Also both the

Does this make more sense?

I'll be gone this weekend so if you don't hear back, I'll be online
Monday morning.

Eric