[Biococoa-dev] BCSequence class cluster

[Koen van der Drift]

Alright,

Some time now to reply :)

For more info on class clusters, also checkout the page at CocoaDev:

http://www.cocoadev.com/index.pl?ClassClusters

BTW, CocoaDev has a lot of very interesting pages.


> They would have some init methods, but when the user uses these 
> classes and alloc/init an instance, she would get in fact one of the 
> BCSequence subclasses. The compiler would not know and would trust the 
> headers to generate warning. For instance, the header for the 
> BCSequenceProtein placeholder class would not define the methods 
> 'complement' or 'cutWithRestrictionEnzyme:',

Proteins can be digested as well, so I suggest we just use a general 
digest tool class. Just feed it a site where to cut, and the tool 
returns an array of locations, or subsequences.

> I'm still wondering a bit how we're going to implement these kind of 
> methods, as we now have to start ALL methods with a test what the 
> sequence type is.

You only need to put the test in the init of the BCTools subclasses. No 
need to keep them in BCSequence, et al. Another  possible solution 
could be to create a DNATools/ProteinTools class, which has convenience 
methods to various manipulations only for that type of sequence (this 
is the BioJava approach - I like the first one better, though).

>
> No, there is no test at the beginning of a method. It is simply coded 
> in the subclass. For example, BCSequenceProtein could override the 
> 'complement' method to return an empty sequence. Actually, this is not 
> such a great example as 'complement' can easily be taken care of by 
> the superclass which would call 'complement' on the BCSymbol objects 
> of the symbolArray.

So, if I understand this correctly, when using class clusters, we still 
need to subclass each method? Not sure if I like that idea now :). As 
you remember, the reason I was trying to convince you guys to avoid 
subclassing, was to prevent code duplication in all the subclasses. 
This easily leads to errors and is difficult to maintain. I could of 
course be wrong, and not understand the class clusters completely yet.


> Now I have an additional comment on what to do with strongly typed 
> instances, when the user is purposedly using a BCSequenceProtein, has 
> a call to 'complement' and ignores the compiler warning and runs the 
> program. It would then be nice to have run time error (yeah, this is 
> nice!) when calling a method on a strongly typed instance. For this we 
> could have an additional flag 'isTyped' and have the private 
> BCSeqProtein check the value of the flag in the critical methods, and 
> raise an exception if isTyped=YES or call super if =NO.

Again, maybe I don't understand the class clusters yet, but isn't the 
idea to have users only use BCSequence, not BCSequenceXXX?  I agree 
with Alex about not using flags, though. We have introduced the 
BCSequenceType and BCSymbolSet (my preference) to identify the type.

>
> To implement mutable objects in the class cluster could be a bit 
> tricky, because there are two conflicting subclass organizations here: 
> mutable/immutable and dna/rna/protein/codon. To get all the 
> combinations, it seems that we need 8 subclasses!!
> Oops, Koen won't like this, LOL ;-) On the other hand, look at the 
> number of NSNumber subclasses...

No, I don't like that :D, see my comment above. Another possibility 
(also stolen from BioJava) is to make a BCToolsEdit class that takes 
care of editing a immutable class.

>
> OK, I'll stop there, hoping teh europeans will get that before going 
> to bed.
>

Although European, I'm in North Carolina, so I have a few more hours. I 
will respond some more maybe later tonight.


cheers,

- Koen.