[Biococoa-dev] more on BCCodon

[Alexander Griekspoor]

Back online after a food-poisoning on friday (which struck Tom as well, 
join in for a dinner at our institute's restaurant ;-) and a weekend 
away, I'd like to chime in here... I will also go through the code and 
previous emails of this weekend in later replies if I have some time 
later on, but this seems more a definition issue.

>> The problem with codons is that they don't really fit neatly into the
>> defined classes.  There's always a few methods in the Symbol and 
>> Sequence
>> classes that don't make any sense when applied to a codon.

> What's the advantage of subclassing BCSymbol compared to BCSequence? 
> Again, it's a sequence, so subclassing BCSequence seems more logical 
> to me.

The way I see it, you have a list of Codons that together make up a 
Sequence of Codons. Thus, BCCodon in that respect would be the symbol 
(so a subclass of BCSymbol) and BCSequenceCodon  would be the sequence, 
a subclass of BCSequence.
All confusion seems to come from the fact that BCCodon has a (very 
important) variable that is a BCSequenceDNA, but than again it also has 
a amino acid variable. If we make BCCodon a BCSequenceDNA subclass I 
think the balance is completely shifted to its DNA half, and the 
aminoacid half makes quite a strange appearance in there. In my opinion 
we should compare a codon to a amino acid or nucleotide, thus as a 
entity that makes up a sequence. The codon per se is not a sequence, a 
list of codons is. Perhaps the best comparison to real life is that 
with the tRNA. On the one side a tRNA has it's RNA complement of three 
bases, on the other side it carries the amino acid. Whether I'm missing 
things here is something I'll probably find out soon after reading 
through all other emails ;-)


> You don't have to use all methods that are provided by the superclass, 
> so I don't think it is a problem.
Well yes and no, you don't have to use them, but they must return 
something that makes sense. If you feed a codon in a method that 
accepts BCSequences in general, it could terribly crash if BCCodon 
doesn't know how to interpret things.

> If I know that an object is a sequence, I will just call [mySequence 
> sequenceString] to get an NSString, and I don't have to worry that the 
> method doesn't exit, or is named differently. BCCodon now uses 
> 'tripletString' to return an NSString, just as it uses 'triplet' 
> instead of sequenceArray. That's the beauty of inheritance. I don't 
> see any reason why to treat BCCodon differently, to me it's a sequence 
> of three nucleotides.
The one thing doesn't prevent the other. We can still, for clarity, 
keep a lot of method names the same, even if they are not subclasses. 
In fact, this is something you see all-over the appkit as well, and I 
would strongly recommend to keep our basic set of method names as small 
as possible. For instance, this afternoon I noticed that both NSBox (a 
NSView subclass) and NSWindow (a NSResponder subclass) have a 
-(id)contentView; method which does exactly the same thing in both 
cases.

> Moreover if all classes that deal with sequences use the same method 
> naming, it becomes much easier for users (and us) to use BioCocoa. If 
> every class uses a different approach, things get more unclear, and 
> more difficult to maintain.
Exactly my point, but again that doesn't require subclassing per se. 
Also I was thinking from a user perspective (remember it's a developer 
here, so code organization is key here) that we can organize things a 
bit better still, like moving BCCodon to the symbols group, moving the 
symbols folder to the root instead of inside BCSequence etc. But I'll 
make a wishlist one of the next days ;-)

Great work guys!
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

    The requirements said: Windows 2000 or better.
    So I got a Macintosh.

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