[Biococoa-dev] BCSequence class cluster was:(no subject)

[Alexander Griekspoor]

>> What about using _BCSequence instead of BCSeq? Whith the underscore 
>> we know exactly what tyoe of class we're dealing with, BCSeq <-> 
>> BCSequence seems more confusing to me.
>
> That indeed may be a better naming scheme, though I have never seen 
> that applied anywhere (a bit unorthodox?). It seems that ivar starting 
> with undescore are supposedly reserved for Apple now, but these would 
> be class names, not ivars, so technically, we would not breaking the 
> rules!

I like the underscore variant as well. Charles, I heard that too, in 
principle ivars with underscores are reserved to Apple, although I've 
seen many opensource projects already where people use underscores for 
private ivars...

> (about the purpose of BCSymbolList)
>> Not sure yet how the user should approache this :). In general there 
>> should be one class that is always used throughout. Now I think of 
>> it, BCSequence is really the best choice for it. Annotations are a 
>> nice extension, but not always needed.  Maybe we should dump 
>> BCSymbolList at all, and only use BCSequence. It can have an empty 
>> annotation ivar, which is not very costly. One of the reasons to 
>> introduce the BCSymbolList was to avoid the introduction of even more 
>> subclasses classes with long, clumsy names such as 
>> BCAnnotatedDNASequence.

Yes, I agree, if we can get rid of BCSymbollist and only have one class 
(BCSequence) that would have my preference too. Just my stupidity, 
adding many methods to a class (which we need to keep annotations in 
sync and add/remove them etc) doesn't make it more costly to use  
memory/speed wise?

> OK, so it seems the main purpose was to provide a light-weight version 
> for non-annotated sequence. It seems at some point, when adding 
> annotations, the team decided to subclass BCSequence into 
> BCAnnotatedSequence. The renaming then was a way to avoid long class 
> names  (that I remember now from reading the archives) .
Correct.
>
> I totally agree that an ivar for annotation is not going to use much 
> memory if nil (4 bytes) or empty (4 bytes + sizeof(ivars of NSArray)), 
> particularly when you already have an NSArray for the sequenceArray 
> that should contain in 99% cases at least 10 items (peptides), and 
> most of the time many more (think plasmids!). So "light-weight" class 
> is actually probably wrong.
;-)
>
> However, I could see the case for code separation, the superclass 
> without annotation taking care of the non-annotation methods, and then 
> the annotated subclass taking care of the annotation-related methods.
Exactly my point, I'm not sure though, the first (and foremost) 
question is whether putting everything in one class doesn't matter 
memory/speed wise (I'm not talking about the small unused ivars). 
Second, how much will the sequence class increase code-wise to a point 
where things become unpractical. For example, I have experienced 
opensource projects where classes have become so extended that you 
can't say extract one class for use in a custom project without 
spending hours unwinding everything unnecessary, where with a class you 
basically have to incorporate the whole project to make it work. Maybe 
not so much of importance, but usually the more simple the code and 
easier to overview, the more useful and versatile it turns out to be.

> In this case, the current BCSymbolList could be an abstract class and 
> remain hidden in the class cluster as a private subclass, at the top 
> of the class hierarchy, just below the pulic class (or it could BE the 
> public class; this goes back to my previous emails with the different 
> propositions for class hierarchies). We end up with one public class 
> being able to do everything, and all the concrete private subclasses 
> capable of handling annotations.
>
> If the purpose is to separate the code for annotations, an alternative 
> is to use a category, and not a subclass. And I think I like that 
> better, actually.
As said before, I'm not really in favor of categories as they don't 
really belong in a framework, BUT as they are private things maybe 
different.

> My feeling after all these discussions about annotations is that we 
> should be able to make annotations a general and abstract concept that 
> encompass all the different types of sequences, which means most of 
> the code could go in the superclass.
Yes!

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

               4Peaks - For Peaks, Four Peaks.
        2004 Winner of the Apple Design Awards
                Best Mac OS X Student Product
              http://www.mekentosj.com/4peaks

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