mutable or immutable features? (was: [Biococoa-dev] Comments on BCAnnotation)

[Charles PARNOT]

At 11:17 +0100 2/24/05, Alexander Griekspoor wrote:
>>>After going through your code, Alex, here are my comments:
>>>
>>>* we should make BCAnnotation and BCFeature immutable and thus not have any setter; for instance, the annotations would otherwise have to be physically copied every time a piece of sequence is copied and pasted or used for alignement, etc...
>>you are definitly right. There is perhaps one problem, but perhaps it isn't a real problem ;-)... what happens with the BCFeature positions if i insert gaps into the sequence. If the positions have no set method everybody has to know that this positions are the ones without gaps.
>>I'm also not sure wether we need a special BCSequence class for alignment or not. Perhaps we need only a BCMutableSequence with the corresponding BCSymbolSet including a gap-symbol. This is open for discussion ....
>
>Annotations can be immutable as they are position independent indeed, but per definition the range of a BCFeature of a mutable sequence (which ours is at the moment) should be mutable as well. Good thought Phil...

Well, I would still stick to an immutable version. Here is why.

When you modify a sequence, you have to change the positional information in the features. If a feature is mutable, you will want to make a copy first and then modify it, though, because you don't know if the feature instance is not shared with another sequence, and the range you are modifying would not apply to that other sequence. Or to avoid that, when you copy a sequence, you would also make a physical copy of the feature so you know a feature object is not shared between sequences. In both approach, you still don't know what the user of the framework might do with the feature if it is being returned through the accessor in the sequence object. So the accessor should return a copy too, just in case. You end up physically copying the features all the time one way or the other, and the user of the framework may be doing the same too, even when maybe it would be OK to share the instance because nobody is going to modify it. But you never know, so you just copy.

The bottom line is: if we agree that features might be shared by different objects (which you may say is not the case), then every time you  modify a feature, you have to copy it first just in case.

On the contrary, with an immutable feature, you don't have to physically copy it all the time, you know it will never change. Even the -(id)copy method can simply return self  (and retain it).

Of course, the issue raised by Phil is still valid. But because the only modif would be on the range, you could have a method like this:
	- (BCFeature *)featureWithNewRange:(BCRange)newRange;
returning a new autoreleased object, copy of the target and with a new range.

charles

-- 
Help science go fast forward:
http://cmgm.stanford.edu/~cparnot/xgrid-stanford/

Charles Parnot
charles.parnot at stanford.edu

Room  B157 in Beckman Center
279, Campus Drive
Stanford University
Stanford, CA 94305 (USA)

Tel +1 650 725 7754
Fax +1 650 725 8021