[Biococoa-dev] more ramblings

[Alexander Griekspoor]

> Well let me add some points here. Although I never liked the idea of 
> subclassing BCSequence, I think you guys are right that if we use 
> one-liners it is better to call them from the appropriate subclass. 
> But I still like the idea of have the wrapper test the sequence type 
> first before continuing. It might be nonsense to do that, but the 
> result won't be - because there are no results.  Just returning nil 
> will be sufficient, no need to start throwing exceptions around ;)

True, the question is how we organize the wrapper (you mean the 
BCAnnotatedSequence right, or whatever we decide to name it). There are 
basically two choices either let the developer separate the sequence 
from the annotations/features part and do all manipulations purely on 
the BCSequence, or make all methods accept besides BCSequences also the 
BCAnnotatedSequences. This latter his some clear advantages (such as 
the possibility to take features into account while calculating the MW 
for example), but it also has some clear problems. One thing it would 
mean is that we are almost forced to have also three types of 
BCAnnotatedSequence subclasses around (Koen might remark the benefit of 
a single BCSequence class here probably). In general the first option 
is what we want I think, BUT I haven't thought of a way to do the 
features that are connected to ranges within the sequence.

Notes and annotations like creator, date etc are easy, they don't 
change (and are what I would call a BCAnnotation). Features (BCFeature 
objects) are much more of a problem, they are coupled to sequence 
ranges (i.e. a helix from aminoacid 10 to 15), and should be kept in 
sync while editing the sequence. The big problem here is, what 
architecture would be the smartest way of doing this. Any suggestions?
>
> My main reason for being against the subclassing was because at the 
> time that I brought it up there was so much code-duplication, that I 
> was wondering if there was a way to make it easier to maintain and 
> understand. We didn't talk much about one-liners and convenience 
> methods then, which is indeed a reasonable argument pro subclassing,   
> However, I don't like the idea that was suggested in another recent 
> mail, to also make subclasses for DNAStrict, proteinstrict, etc.
I copy that, definitely not, but the general BCSequence class could 
have a simple strict boolean that can be set. Also, we can introduce 
the strict BCSequenceTypes for passing as arguments...

> These are only variations on the existing three subclasses, and should 
> be differentiated from each other by their symbolset and/or 
> sequencetype.
Yep
Cheers,
Alex

*********************************************************
                     ** 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

       Microsoft is not the answer,
       Microsoft is the question,
       NO is the answer

*********************************************************