[osmosis-dev] Tags class

[Brett Henderson]

Marcus Wolschon wrote:
> On Thu, 5 Feb 2009 11:56:26 +0100, Jochen Topf <jochen at remote.org> wrote:
>   
>> Why do we have two implementations for Tags, one is modifiable and one
>> not? If we do have that we should bring those together, shouldn't we?
>> Isn't the unmodifiable thing only to make things easier for
>>     
> multithreading.
>   
>> I haven't looked at the details, but I could imagine something like
>> class Node that has no setter methods and child class ModifiableNode that
>> has setter methods.
>>     
>
> The ModifiableNode is not to return a non-modifiable Tag and
> the Node is not to return a modifyable tag-list. Same for Way
> and Relation.
> Brett wanted the immutable versions but added the -Builder-classes
> to ease the construction of entities in complex cases.
>   
Yep, the intent was to enforce immutable data exchange between tasks to 
guarantee thread safety and provide builder classes to make it easy to 
manipulate them.  I think the current implementation is fairly neat but 
the entity classes are very simple.  My original intent was to keep the 
entity classes minimal and add all specialised logic outside them.  If 
we're going to start moving functionality into the entity classes 
themselves (eg. the isClosed method) then the entity/entitybuilder 
design may become tedious to maintain and I suspect we'll have to throw 
away the whole entitybuilder concept and solve threading issues another way.

This is a key decision to be made.  Do we want to allow additional 
functionality to move into the entity classes beyond basic data storage, 
or do we want to keep them minimal?  Keep in mind that whatever we add 
to entity classes will be hard to remove later, particularly as plugins 
become more popular.  I could be influenced either way at the moment as 
you can probably tell by me liking the idea of a new Tags class on one 
hand, but still hanging onto the idea of separate immutable entity and 
mutable builder classes.  My preference is to keep as much logic outside 
entities as possible at this point.  I'm worried about this becoming a 
slippery slope where all sorts of stuff gets added and we end up with an 
inconsistent mess.  The design is fairly clean at the moment but it has 
take some discipline to keep it that way.

I've gotten slightly sidetracked.

With the current implementation we'd probably need two Tags classes.  A 
mutable and immutable version.  The Tag class itself is immutable and 
can be shared between both implementations because a Tag class should 
never need to be modified.  I may have to have a play with this to see 
what it really looks like.

Anyway, on that note I'm heading away for the weekend (taking Friday off 
work) so I'll be back on Monday!  We're supposed to be water skiing but 
with a weather forecast of 45 degrees celcius on Saturday we may spend 
more time drinking beers beside the air conditioner :-)