[Biococoa-dev] BCSymbol Nomenclature

[John Timmer]

>> We move all initialization methods into the subclasses, since Koen and
>> I are
>> writing them and handling them somewhat differently.
> 
> I'm not in favour of this one, can you identify what exactly you do
> differently? I would strongly ask you guys to agree on one of the two
> implementations as both classes are descendents of BCSymbol it would be
> not more than logical to keep implementations as similar as possible as
> well. The aminoacids are encoded through a plist as well aren't they?
Koen's dictionary is symbol based, and I could switch to that easily, and he
could add a chemical name to his.  I could change my "initWithDictionary" to
an "initWithName" and look things up in the dictionary as he does.  All that
would do would be to provide parallel method names, though - they'd still
wind up doing very different things, because the information content of the
individual BCSymbols is going to be quite different.  Compare his:
- (void)setHydropathyValues
To
- (BCNucleotideDNA *) initWithDictionary: (NSDictionary *)entry
To see what I mean.

Even if we force a bunch of parallels, there may still be significant
differences between how things work. Koen can initialize the amino acids
individually as needed, whereas I need to initialize the bases all at once
because of the whole complementation issue that amino acids don't have.  We
could make Koen's initialization code work the same way mine does, but I
think my code's a bit ugly and hard to follow, while Koen's current stuff is
much cleaner.

I see the point that having as many parallels as possible would make it
easier for new people to come in and work on the code, but I'm just not sure
how easily that would work in this case.

One thought I did have about the BCSymbol class -
We could move the .plist dictionary loading and validation code there.
After all, if one is missing or damaged, I wouldn't trust the other, and we
could have a common exception throw for indications of bundle damage.  Does
this sound good?


> Please leave the accessor methods, but make them private. This is the
> recommended way apple advises us to go. Things are more straight
> forward for people to read the code and prevents making mistakes. Thus
> in the .m file:
> 
> @private
> -(void)setName:(NSString *)name;
> @end
> 
> init...
>   [self setName: @"blabla"];

Is there any reason this is preferred to :
 name = [entry copy];
If you don't want the name changed, I'd prefer to not make any way of doing
so short of creating a new object.  But maybe that's just because I always
assume maliciousness on the part of my users....


 
> Commonly the symbol for stop is an asterix "*", please use that one.
> Also a stop is kind of an ambiguous aminoacid like W is an ambiguous
> base. Do we provide this one in addition to the three stop codons we
> know? Also, how do we implement the fact that in one species something
> can be a stop codon, but in another not? This influences the symbol
> right?
Well, that's where we use a BCCodonSet - send the translation method both
the sequence and the set.  We could have an enumeration of sets
(BCUniversalCodonSet, BCVertebrateCodonSet, etc.) corresponding to integers,
as Apple does for many things, and have the sets defined in a .plist, which
is working well for us.  How a program chooses which codon set to use,
however, isn't our problem - we just provide the facility to do so.

And * is fine with me.



_______________________________________________
This mind intentionally left blank