[Biococoa-dev] Compilation warnings with tools

[Koen van der Drift]

Charles,

Thanks for the explanation. Right now I am nursing a slight hangover 
from last nights Mardi Gras / Carnaval party ("laissez les bonnes temps 
roulez"), so correct if me I am say something stupid :)


>> NSArray *translation = [BCToolTranslatorDNA translateDNASequence: 
>> theSequence usingGeneticCode: BCUniversalCodeDNA];
>>
>> [BCToolTranslatorDNA translateDNASequence:] is expecting a 
>> BCSequenceDNA instead of a BCAbstractSequence. That one is easily 
>> fixed, and I will commit that.
>
> This is an important point to understand about the tools, which I 
> mentioned briefly during last month's discussion. For some of the 
> tools, we will have to define 2 methods, depending on the type of 
> sequence we pass. This is the only way you can have both strong and 
> weak typing:
> - (NSArray *)translateSequence:(BCSequence *)theSequence 
> usingGeneticCode: BCUniversalCodeDNA
> - (NSArray *)translateDNASequence:(BCSequenceDNA *)theSequence 
> usingGeneticCode:code;


I don't understand why there have to be two methods, instead of one 
general like this:

-(NSArray *) translateSequence: (BCSequence *)sequence 
usingGeneticCode: code


>
>
> Note that he implementation would  be trivial for the BCSequence 
> version.
>
> However, duplicate methods are really necessary only if the tool is 
> public, if we let the framework user access it directly. On the 
> conrary, if the tool is private and 'hidden' in the BCSequence 
> interface, then there is no need to duplicate method names. The 
> BCSequence can be used transparently only when dealing with methods in 
> the sequence classes.
>
> Let me explain with the translation example.There could be a method 
> 'translatedSequenceUsingGeneticCode:', only relevant for 
> BCSequenceDNA, which would have the following implementation in the 
> different sequence classes:
>  * Interface of BCAbstractSequence and non-relevant subclasses: the 
> method is not declared (you get compiler warnings)
>  * BUT implementation in BCAbstractSequence: the method exists and 
> returns an empty array; this will also be the default behavior for 
> non-relevant subclasses; thus, even though the method is not declared, 
> it is implemented and will not fail at runtime if called on a 
> non-relevant subclass (this is crucial for BCSequence behavior, see 
> below)
>   * BCSequenceDNA: the method 'translatedSequenceUsingGeneticCode:'  
> is declared in the header; in the implementation, it overrides the 
> superclass, and this is really that subclass that uses the private 
> tool;
>  * BCSequence interface: the method is declared (hence no compiler 
> warning)
>  * BCSequence implementation: does not implement anything... but it is 
> never instantiated! Real instances created thru BCSequence are one of 
> the other subclasses; all the subclass will return something, either 
> through the superclass implementation (empty array), or something 
> relevant if the instance happens to really be a BCSequenceDNA; so 
> BCSequence will behave properly at runtime too.
>
> This may be a bit complex to understand at first you just have to go 
> through all the different cases to see what happens. But the 
> implementation itself is simple.
>
> The bottom line is that it may be easier to make the simplest tools 
> private, so we don't have to declare more methods. These tools would 
> then be hidden in the BCSequence implementation, and only available 
> through their interface. In the case of translation, this is clearly 
> the way to go. Using a tool makes thing more convoluted.
>


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.


cheers,

- Koen.