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

[Charles PARNOT]

>On Feb 24, 2005, at 9:57 PM, Charles PARNOT wrote:
>
>>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,
>
>I don't understand this last part. Can you explain why a feature can be shared between more than one sequence? The way I see it, if two sequences have the same feature they both should have a separate BCFeature object to contain that information.
>
>- Koen.

It could be shared if you copy a sequence. Or you paste a piece of sequence somewhere else and the position is the same. Or you copy a sequence to do an alignment. Because the sequence objects are mutable, you have to physically copy them before using them in another context, which means physically copying any mutable ivar.

It is still debatable how often this will happen, of course. I think there is a part of psychology here, as  immutable objects are less likely to cause trouble in the future and will let you code in peace. For instance, in my current application for my project in the lab, I am using a parameter class which I made mutable at the beginning because I thought it would be easier. I end up worrying all the time: should I copy the object before doing this or that? Because when the code grows bigger, you tend to lose track of where and why objects could be shared with other objects. Now I really wish I had created immutable objects instead.

Don't you find yourself mostly using immutable objects (NSString, NSArray,..) when they might be used out of the scope of a method or out of a scope of a class (e.g. public ivars), and mutable objects WITHIN the scope of a method or when you know these ivars are going to be private. Maybe I am paranoid, though!!

My final argument would be: it does not really cost much to use immutable features instead of mutable features because they are light objects, containing immutable ivars. So a copy is really just allocating a few bytes to copy the addresses of the ivars.

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