[Biococoa-dev] (no subject)

[Charles PARNOT]

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

This is how I get started a few months ago with my fitting program 
where I decided to implement class clusters. It turned out to be 
quite easy. Adding subclasses is easy too.


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

This is EXCELLENT. The more general the approach, the more 
encapsulated, the easier it will be to write and maintain and keep as 
much backward-compatibility as possible.



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

OK, I should have been clearer. As much as possible, we should keep 
the implementation in the superclass. And actually, 'complement' is 
an excellent example of it and how the abstraction you have set up 
for BCSymbol works well. When the case can be handled by the 
superclass, we should do it. Most of the BCSequence methods in my 
mini-project can be handled at the superclass level, I now appreciate 
more

There might still be cases where specific methods have to be written 
for a specific type of sequence. It is then easy to add the method to 
the subclass, instead of having some case of if statements in the 
superclass. This is more elegant and easier to maintain. I know you 
already had the discussion with Alex. No matter what you do, if a 
type of sequence has to be treated separately, you have to write two 
different versions of a particular piece of code. It is actually 
easier to separate the two cases in two separate methods for two 
different classes in two different files. It still think I see your 
point. The only problem with subclass is that it is quite easy not to 
realize that you are duplicating code. It is more apparent when you 
have a series of if statement in front of your eyes, all with the 
same contents. You can also more easily spot the common stuff. Having 
subclasses does not force you to duplicate code, it just tends to 
happen more frequently.



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

Yes, sorry about the confusion. I was just proposing a possibility in 
case the user complains she wants more strongly typed classes. I 
agree it goes against the concept of class cluster and its 
simplicity. I was just trying to show that even in the context of a 
class cluster, there are ways to still propose some more strongly 
typed headers without too much efforts, and give the option to the 
user. It seems Alex and you don't really ask for that, and I like the 
simplicity of just one public interface too. Let's just forget about 
that or bring the issue back later.


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

I can see that: then BCToolEdit would havbe to return new instances 
(otherwise it is not immutable anymore), but would deal with 
optimization better than a dull 'copy'.


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

Can't wait for more!!

Charles

-- 
Charles Parnot
charles.parnot at stanford.edu

Help science go fast forward:
http://cmgm.stanford.edu/~cparnot/xgrid-stanford/

Room  B157 in Beckman Center
279, Campus Drive
Stanford University
Stanford, CA 94305 (USA)

Tel +1 650 725 7754
Fax +1 650 725 8021