[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 ;-)
> 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
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.
>> 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 ;-)
More information about the Biococoa-dev