Re: [Tm4j-developers] some thoughts of TopicMapCopier

[Gerd M. <ge...@sm...>]

Hi,

> thats a lot of stuff and new thoughts which are mixed together.
> 
> 
> - having static copy methods
> - where the methods will reside
> - putting complex code in base classes
> - thinking about backend stuff
> - putting a copy factory in topicmap
> 
> Having static methods is sure a quite good deal. I don't really have
> 
> a preference where they should live.
> The static methods could reside in the object implementations while
> they are object specific. On the other side every static methods
> gets his working stuff as a parameter. This opens the options to
> put them into an extra class.
> 
> If I understand you right then the copyFactory has something to do
> with the deep copy. In this situation we need a factory for creation
> of subcomponents. If I assume the static methods we have
> 
> 	copy(Topic srcTopic, Topic destTopic, boolean deep)
> 
> On the other site we have in TopicMap
> 
> 	setCopyFactory(TopicMapFactory copyFactory)
> 
> I think it is dangerous to assume that the factory of destTopic and
> copyFactory are always the same. In my opinion we should have an assurance
> that the factory of e.g. a Topic and his components (BaseName, Occurrence)
> is the same. If this isn't clear here a example:
> 
> 	Topic src;
> 	TopicMapFactory f1;
> 	TopicMapFactory f2;
> 	TopicMap tm;
> 
> 	tm.setCopyFactory(f1);
> 	Topic dest = f2.createTopic();
> 
> 	Topic.copy(src, dest, true);
> 
> What will happen? A Topic src in a TopicMap from f1 and BaseNames
> in TopicMap from f2 ??
> 
> As long as I can see TopicMap is the only class which knows his factory.
> That looks good. Is there any reason why a TopicMapObject shouldn't
> know his Map? Every Object is only working in one TopicMap (through
> references). If every TopicMapObjects knows his Map/Ownermap we could
> check such things like illegal movement from one topicmap to another.
> And we can always get the right factory through 
> this.getOwnerMap().getFactory();
> This way we wouldn't need copyFactory, we could use loads of different
> factories and the case of copying from a memory map to ozone is coped.

Maybe I missed some point in this discussion, but why not having
a copy() method at the factory interface ? Then I would write:

  Topic t = factory.copy( topic, true );
     
Then it would be clear in which topicmap the copy resists and it
doesn't matter where the source comes from. 

> 
> backend ideas:
> 
> Today I asked about the interface and implementation stuff of the
> backends. My thoughts were the same as kals that there should
> be the possibility to have a single implementation of topicmap
> administrative code.
> At the moment there is an API which copes with TopicMaps and not
> with backends. Through the lack of a definition of a backend the
> TM API itself is made backend specific. For me thats the point
> of doubling implementation in the memory and ozone code.
> I think the backend has total different requirements than the
> TopicMap. If we could define the requirements for a backend
> and turn them into atomic backend operations and then into interfaces
> we could easily build a pluggable backend. I don't know if there
> are reasons while this would be a too heavy task. Gerd?

That'S a nice idea. It would make it easier to develop other
backends. But I'm not sure if it is really that easy to define
such atomic operations. Do you've got any ideas on that ?

Bye,
gerd

--
________________________________________________________________
Gerd Mueller                                    ge...@sm...     
SMB GmbH                                  http://www.smb-tec.com