Re: [Tm4j-developers] some thoughts of TopicMapCopier

[Kal A. <ka...@te...>]

At 13:45 27/09/2001 +0200, Norbert Hartl wrote:
>Hi,
>
>[kal]
>
>I am very lucky to see that the copying stuff has just started.
>It's one of those functionalities I need most these days.
>I had a peak view at the TopicMapCopier class. And from there
>some questions arose.
>
>As long as I understand the copying problem it depends on
>the origins (or factories/owners) of the objects and the type
>of copying (shallow/deep).
>
>involved objects/params are:
>
>- sourceObject
>- destObject (created from sourceObjects factory or a different one)
>- shallow/deep copy switch
>
>which in my thoughts would lead to a basic method
>
>copy(srcObj, destObj, deep)
>
>in case of class Topic:
>
>copy(Topic srcTopic, Topic destTopic, boolean deep)
>
>This method could be a static method of class topic.
>Or like an example in Collections class collected
>in a utility class (see Collections.copy(List,List)).
>
>Having such static methods it is easy to create other
>needed functionalities e.g. clone().

Thats a good point.

>assuming factory is the factory of the topicmap containing
>srcTopic a clone() method would be like that:
>
>public Object clone()
>{
>    Topic dest = factory.createTopic();
>    return copy(this, dest, false);
>}

That could be done too.

>Additionally we don't need all time to create a util class
>to duplicate an object.

Definitely an advantage.

>If we have the copying functionality in the object itself
>the utility class could cope with comfortability. In the
>present TopicMapCopier the factory is always the same.
>So we could store one specific factory in the TopicMapCopier
>and create copies of Objects automagically.
>
>This would lead from
>
>    public Topic copy(Topic t)
>    { ... }
>
>    to
>
>    public Topic copy(Topic t, boolean  deep)
>    {
>       Topic ret = m_dest.getFactory().createTopic....;
>       return Topic.copy(t, ret, deep);
>    }
>
>or something similar.

Perhaps we could eliminate TopicMapCopier completely and make the factory 
to be used for creating copies into a p

>I would also prefer not to use two different method names
>like copy() and deepCopy(). If there are requirements to
>have automated decision of shallow/deep this comes into place.
>The kind of copy is done via a switch. A switch mostly forms
>itself as an ifElse statements.
>While the method names are chosen at compile time the programmer
>using the API has to write an ifElse statement to decide which
>copy should be made. With a switch in the method this functionality
>moves into the API and appears more comfortable.
>Additional there is the possibility to define a default behaviour
>having a method without the switch parameter.
>
>what do you think?
>
>NoB
>
>
>_______________________________________________
>Tm4j-developers mailing list
>Tm4...@li...
>https://lists.sourceforge.net/lists/listinfo/tm4j-developers
>