[Biococoa-dev] BCSequenceRecord

Alexander Griekspoor mek at mekentosj.com
Mon Jul 11 04:41:32 EDT 2005

I totally miss the point, my proposal was to have an header like this  
for the immutable class:

NSMutableData *seqdata;

- (NSData *)data;

the implementation:

- (NSData *)data {
     return seqdata;

I don't see how the underlying data could change because there are no  
public methods to edit the data. The compiler will beep when you do  
try to edit the mutabledata object outside the sequence object  
because the method tells you it's immutable (which it isn't in  
reality of course).

The mutable class overrides the -data method to:

- (NSMutableData *)data {
     return seqdata;

But perhaps there are way better approaches. I think our biggest  
problem is that we have kind of 2d inheritance we would like, both in  
the direction of mutable vs immutable, and in the direction of DNA,  
RNA, Protein, etc. What's the best approach to do that? This would be  
absolutely the biggest argument in favor of the single sequence does  
it all method (untyped sequence, typed by the symbolset).


On 11-jul-2005, at 2:11, Charles Parnot wrote:

> On Jul 10, 2005, at 1:16 AM, Alexander Griekspoor wrote:
>> <snip>...Anyway, I would have no problem to make the public method  
>> return an NSData but the private property be an NSMutableData,  
>> also for the immutable sequence....<snip>
> I think we should not do that. This is very dangerous. In most  
> cases, it will go unnoticed, but in certain configurations, this is  
> the path to very weird bugs in programs using the framework.
> Let me give you an example where that would be bad. The user  
> implements a very rudimentary undo, simply by saving the contents  
> of the sequence at each manipulation (let's say she does not know  
> about the NSUndoManager!!).
> So every time the user changes something:
> NSData *currentSequence = [mySequence data];
> [myMemoryStack addObject:currentSequence withKey:[NSDate date]];
> and then later wants to go back to the sequence 2 hours ago:
> NSData *previousSequence = [myMemoryStack  
> objectForKey:twoHoursAgoDate];
> oldSequence = [BCSequence sequenceWithData:previousSequence];
> Well, the data retrieved then will actually be the data  
> corresponding to the sequence as of right now, because the pointer  
> was actually to the actual data object in the sequence, which has  
> been mutated since...
> You only return a mutable object instead of a non-mutable, when you  
> just created it on the fly, do not share it with any other object,  
> and you are (auto)releasing it anyway and are not going to modify it.
> Of course, for performance, you could still return the muutable  
> data object, and do a lazy copy of the data if needed, later, when:
> * the data is asked by another object
> * the data  is being modified
> (so you need some sort of flag for that).
>> But if there is a way to have the immutable bcsequence have an  
>> NSData property and the mutable version have an NSMutableData then  
>> that would be more elegant obviously...
>> Cheers,
>> Alex
> You can set an ivar to be NSData, but make it an NSMutableData  
> anyway. With the proper casts, the compiler won't tell anything,  
> and the runtime won't bother... As long as you don't call the wrong  
> methods on the wrong type!!
> Another option to avoid the casts is to type the ivar as an 'id'.  
> But then you don't get any compiler checking, of course,...
> charles
> --
> Xgrid-at-Stanford
> Help science move fast forward:
> http://cmgm.stanford.edu/~cparnot/xgrid-stanford
> Charles Parnot
> charles.parnot at gmail.com

                     ** Alexander Griekspoor **
               The Netherlands Cancer Institute
               Department of Tumorbiology (H4)
          Plesmanlaan 121, 1066 CX, Amsterdam
                    Tel:  + 31 20 - 512 2023
                   Fax:  + 31 20 - 512 2029
                   AIM: mekentosj at mac.com
                  E-mail: a.griekspoor at nki.nl
               Web: http://www.mekentosj.com

               4Peaks - For Peaks, Four Peaks.
        2004 Winner of the Apple Design Awards
                Best Mac OS X Student Product


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.bioinformatics.org/pipermail/biococoa-dev/attachments/20050711/0aebff72/attachment.html>

More information about the Biococoa-dev mailing list