[Biococoa-dev] Compilation warnings with tools

[Koen van der Drift]

On Feb 7, 2005, at 8:05 PM, Charles PARNOT wrote:

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


Or have one weak typed method as I suggested in a previous post, and 
test for the type in that method. Then either return an empty or useful 
array.



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

That seems like a reasonable 'rule'. I don't see any problems when the 
convenience method is only in BCSequence.


- Koen.