[Biococoa-dev] Compilation warnings with tools

[Charles PARNOT]

>I don't understand why there have to be two methods, instead of one general like this:
>
>-(NSArray *) translateSequence: (BCSequence *)sequence usingGeneticCode: code

This works fine if you only use BCSequence and never relies on the other sequence classes. But if you use a BCSequenceDNA on the above method, you get a compiler warning.

Just to let the possibility for strong typing. e.g. if  John wants to enforce the use of a BCSequenceDNA for that method, then we need a separate method with the BCSequenceDNA typing. An alternative is to use the BCAbstractSequence type and have only one method. But then it would also accept BCSequenceProtein, etc...

An alternative is to define a 'BCSequenceDNA' protocol, that both BCSequence and BCSequenceDNA would follow. I am not a big fan of protocols, but that may be a nice use of them. Importantly, the user would not have to worry about the protocol.

Bottom line: it might be best to have both methods. The 'generic' one would test for the sequence type, and return an empty array if non-relevant type, or call the method for BCSequenceDNA if the sequence is indeed of that type.


>I still believe that we should keep the BCSequence class et al as clean as possible, and put all the manipulations in a separate class. The way I see it to use the tools classes is as follows:
>
>myTool = [BCSequenceToolFoo toolFooWithSequence: BCSequence];
>
>[myTool setParameter1: param1];
>[myTool setParameter:2 param2];
>
>result = [myTool doSomethingWithSequence];
>
>This way we keep the framework modular, and don't clog BCSequence with code that works for some classes in one case, and other classes in another case.  It will also be more confusing for the user when some methods are in BCSequence, other ones are in a separate BCSequenceTool subclass.  However, we can alsways have convenience methods in the BCSequence classes to the BCSequenceTool classes that takes care of some very general situations. If the user needs some more special manipulations (s)he can always use the approach as I sketched above. Also making some tools private and others not is confusing, so we should stick with one approach, I think.
>

I completely agree that there should only be one approach, so no tool should be private. I was foolish to imagine the other possibility... Now, what do you think of this other 'rule': to NOT have a convenience method both in the tool (+translateSequence:usingGeneticCode:) AND in the BCSequence (-translatedSequenceUsingGeneticCode:), but only in the BCSequence? I am not completely sure about all this and we may have to see how it works out in the long term...

charles


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

Charles Parnot
charles.parnot at stanford.edu

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

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