[Biococoa-dev] more on BCCodon

Koen van der Drift kvddrift at earthlink.net
Mon Sep 6 20:52:12 EDT 2004


On Sep 6, 2004, at 6:10 PM, Alexander Griekspoor wrote:

> Back online after a food-poisoning on friday (which struck Tom as 
> well, join in for a dinner at our institute's restaurant ;-)

Mosselen?


> 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 ;-)


That's a very good explanation for me, and makes things much more 
clearer.  So I think this suggestion from Alex would be a good 
solution:

BCSymbol -> BCCodon (with BCCodon having a BCSequenceDNA as member)
BCSequence -> BCSequenceCodon


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

Why? The abstract method takes care of for instance returning 'nil' in 
such a case. If it isn't implemented in BCCodon, than BCSymbol should 
take care of it with a default response. If you want BCCodon to do 
something else, then just override it.



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

Good point.

>
>> 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 ;-)

Please submit. BioCocoa is still small enough to move stuff around 
(altough it would be less straightforward in CVS ;-)


- Koen.




More information about the Biococoa-dev mailing list