cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: ObjectContext.localObject refactoring
Date Sun, 04 Sep 2011 01:44:35 GMT
Just committed the new method, which is much more straightforward both from the POV of the
internal implementation and from the public API. 

> Just the other day I started to try to explain this to a co-worker and
> essentially told them "don't question it, just use it."  That's
> probably not the best answer.

Heh, exactly :-)

> We need to keep localObject() around for a bit,
> though, for backward compatibility.

This is not a problem. My next step will be to remove internal Cayenne calls of this method,
but it can stay in a deprecated form for as long as needed. I guess I was trying to ask whether
someone is doing something unusual with this method that would not be addressed if this method
goes away eventually.

> I'm still not sure I like the method name localObject().  I think it
> should be clear to the user that it takes an existing object (not a
> new one) in one context and makes a copy of it to be also managed by a
> different context. 


It is hard to express what the method does in one word. There are other aspects to it in addition
to new/existing. And even new/existing separation is not always true. E.g. this method can
be called to transfer a NEW object from the parent context to a child context (because we
can find it by ObjectId), but not a NEW object to an unrelated peer context. So even the new
API will still remain a bit of a "black box", and the users will have to read the docs if
they want to understand it in depth.

From your list 'manage' is probably the closest term, still I think it is rather far away.
All of the suggestions imply we do something with the object argument, while we just use its
ID as a key to find a peer object in the context we are working with. So this method is about
"mapping a peer" (this is probably the shortest definition I can think of that somewhat makes
sense).

Anyways, my suggestion would be to keep 'localObject' name for now. It is not ideal but good
enough IMO.

Andrus 


On Sep 3, 2011, at 8:03 PM, Michael Gentry wrote:

> Just the other day I started to try to explain this to a co-worker and
> essentially told them "don't question it, just use it."  That's
> probably not the best answer.
> 
> I'm still not sure I like the method name localObject().  I think it
> should be clear to the user that it takes an existing object (not a
> new one) in one context and makes a copy of it to be also managed by a
> different context.  We need to keep localObject() around for a bit,
> though, for backward compatibility.
> 
> Throwing some naming ideas out:
> 
> add(object)
> manage(object)
> register(object)
> registerExistingObject(object) -- would be similar to registerNewObject(object)
> 
> In short, though, I agree this API should die.  :-)
> 
> mrg
> 
> 
> On Sat, Sep 3, 2011 at 5:16 PM, Andrus Adamchik <andrus@objectstyle.org> wrote:
>> https://issues.apache.org/jira/browse/CAY-1611
>> 
>> I've got tired of doing:
>> 
>> Artist localArtist = (Artist) context.localArtist(artist.getObjectId(), null);
>> 
>> Aside from causing confusion about the second argument (should it be 'artist'? no,
it should be null), it is still plain ugly. Anyone sees any flaws with the reasoning behind
this Jira?
>> 
>> Andrus
> 


Mime
View raw message