[Biococoa-dev] Compilation warnings with tools

[Charles PARNOT]

At 8:07 AM -0500 2/5/05, Koen van der Drift wrote:
>Charles,
>
>A first comment/question about your new code. I compiled the Translation demo, and now get a few warnings such as these:
>
>Examples/Translation/theController.m:71: warning: passing arg 1 of `translateDNASequence:usingGeneticCode:' from incompatible pointer type

Sorry about that, I forgot to check the compilation of the examples (actually, I suspected at some point there would be some issues, and probably this is why I subconciously (?) forgot to check at the end).


>I understand why I get these, because I am just using BCSequence, instead of one of its subclasses. If put in typecasts, the warnings go away. So for instance
>
>NSArray *translation = [BCToolTranslatorDNA translateDNASequence: theSequence usingGeneticCode: BCUniversalCodeDNA];
>
>Will not give a warning when changed to:
>
>NSArray *translation = [BCToolTranslatorDNA translateDNASequence: (BCSequenceDNA*) theSequence usingGeneticCode: BCUniversalCodeDNA];
>
>
>However, I thought that one of the benefits of the class cluster approach would be that we can just use BCSequence transparantly without having to worry about which subclass we are dealing with. Maybe I still don't understand your approach, could you comment on this?
>
>cheers,
>
>- Koen.

At 4:37 PM -0500 2/5/05, Koen van der Drift wrote:
><...snip...>In the other case:
>
>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;

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.

Note that BCSequence is not yet ready for prime-time yet. I need to add the code...

charles

NB: another email coming about the other compiler warning with the factory class.
-- 
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