[Biococoa-dev] a new design to please everybody

Alexander Griekspoor mek at mekentosj.com
Sun Jan 9 05:53:39 EST 2005


Op 9-jan-05 om 8:47 heeft Charles PARNOT het volgende geschreven:

>> At 2:20 PM +0100 1/8/05, Alexander Griekspoor wrote:
>>> Again, the reason why I came up with the idea of some public headers 
>>> for placeholder classes for typed sequences was to propose the user 
>>> BOTH OPTIONS! (but maybe we should not).
>> That's perhaps the most important question we have to answer first 
>> indeed.
>
> This seems indeed the problem raised by Alex, Peter and John. There is 
> a sense that strongly typed sequences are wanted, and maybe even 
> needed.
Yes, and no, it's more a gut feeling (from someone without that much of 
experience, the question is what that's worth).

>  I stated somewhere that a design decision should also be guided by 
> what the user of the framework wants. And I also realize that several 
> of these users will be you (and maybe the only ones for a while),
an important point indeed.
> so we should try to please us, potential users, too. As both Alex and 
> John clearly would not feel confortable working without strongly typed 
> sequence classes, it seems it would be bad to prevent their use.
>
> On the other hand, a good-for-all BCSequence object, that will blindly 
> respond to almost any requests (to some variable extent), is wanted or 
> at least seen as a good thing by several of us too (think WebView). 
> Probably Alex, Koen, Peter and me. There is also some concern, 
> including me, that there may be some limit there. And then, there is a 
> debate over what kind of response would be appropriate for irrelevant 
> messages sent to such a generic objec: runtime error, return nil, 
> BCError, empty object (or self if appropriate)?
That sums it up nicely, thanks!
>
> Now, a little bit of history (already!) on the recent 'class cluster' 
> discussion, viewed from my point of view:
> * It was triggered on my side by the feeling that the current code was 
> getting a bit schizophrenic. It currently allows to instantiate viw 
> BCSequenceFactory a weakly-typed object that will respond to the 
> methods in BCSequence.h (at least from the compiler point of view). If 
> this list of methods is very restrictive (only methods relevant to all 
> types, no -complement, no -hydrophobicity,...), then you get a quite 
> useless object. If this list of methods is large, then you have a 
> problem: due to inheritance, the compiler will assume all the 
> suclasses can respond to the messages; now the subclasses are useless, 
> the compiler think they can respond to anything (hence no compiler 
> warnings)
> * then I (somewhat stupidely) assumed that the latter case was the one 
> favored by the current design, ie a one-for-all class;
In principle, a one-for-all-class would certainly be nicer than a dozen 
subclasses, from a user perspective.
> this is when I thought of the class cluster being a better design in 
> this context; I still think it is for such a one-for-all class, 
> because the sequence tyes are still different enough that they deserve 
> their own class;
Yes, I agree.

> * at the same time, to please some (yet virtual) users willing to 
> stick to strong typing, I came up with the idea of an additional set 
> of placeholder classes with resticted sets of methods in their 
> headers; in the context of a class cluster, other ideas are possible; 
> and actually, these ideas may apply to the current design too; i was 
> thinking this could be added later anyway to please these yet 
> non-existing users;
> * then I realized yesterday that such users actually existed, and I 
> even could see their point; so now my opinion is that we should indeed 
> give BOTH options to the user, which will please all of us (see above 
> why)
Then my answer would be YES!
>
>
> Going back one step, forgetting the class cluster idea for a minute, 
> looking at the current design, and trying to think of what could be 
> done to achieve this, a new idea came up,
> Here it is.
>
> We keep mostly the same implementation as now. The superclass 
> BCSequence is public (but abstract, see why below), and all the 
> current subclasses are concrete and public (BCSequenceDNA, 
> BCSequenceRNA,...). The superclass handles as much as possible the 
> code that can be factored out (including annotations, though an 
> intermediate subclass is also possible, see earlier discussions). The 
> subclasses step in when necessary to replace the superclass methods 
> (for optimizations, specific handling,...). Note that ALL methods 
> should return something, regardless of the relevance (eg 
> BCSequenceProtein should return something in response to -complement, 
> which can done by the superclass, anyway); you will see why below; 
> this can be achieved by having the superclass implement ALL the 
> methods, always returning something not too stupid (-complement 
> actually is already quite smart and in the superclass).
>
> Now about the headers. They are all public, because the classes are 
> all public. We only keep in the superclass BCSequence the methods that 
> apply to all subclasses, i.e. the restrictive set of methods (no 
> -complement, no -hydrophobicity,...). We add the appropriate methods 
> in the appropriate subclasses (-complement in BCSequenceDNA, 
> -hydrophobicity in BCSequenceProtein,...)
>
> And THEN, we add another subclass, for example called 
> BCSequenceGeneric. In the header of this subclass, we put all the 
> methods. This will be for the user a concreate subclass with this 
> one-for-all feel and look (hence 'generic'). And under the hood, this 
> class is like a class cluster (ah! ah! the minute is elapsed; see 
> above). At runtime, you don't get a BCSequenceGeneric instance, but an 
> instance of one of the other subclasses, BCSequenceDNA, ... So no 
> additional code is needed, it is already provided by the other 
> classes. This new generic sequence can be used by the lover of the 
> one-for-all class, and will automatically benefit from the 
> implementation of the other subclass.
>
> As a result, if you use the generic one-for-all class, you can call 
> any method you want and always get something back, without the need to 
> know what is going on (it is in the hands of the user of the final 
> app). However, if you use a typed class, you get appropriate compiler 
> warnings (no runtime error, though). Note that should never use 
> BCSequence (in theory you could, but you would not benefit from 
> potential optimizations in the subclasses).
>
> I am still not sure how to fit the mutable/immutable design in this, 
> but it seems you can't avoid NSMutableSequenceDNA et al. if you are 
> going to have some strong typing.
The latter is perfect, and I like the idea in principle. The only 
concern is if this in the end proves to be too complex. It requires 
very good documentation and tutorials (which we need anyway, but ok) to 
explain all this to a potential new user. Also, it somehow still feels 
schizophrenic, like "we couldn't choose so did both" (which is the case 
;-).
Again, I'm not sure. Sometimes we just have to do what I call the Apple 
approach, instead of giving him dozens of options to tweak and adjust, 
make that choice for the user, and make it so good that the user never 
even wants to change those settings.
Reading all this starts me thinking, "well perhaps we should just go 
for the single sequence setup class cluster thing that reacts to all 
things" and find out if that works, it sounds very oop like and loose 
typing is part of that. Perhaps instead of wanting to strongly type 
things, we just have to check if we get something relevant (non-nil or 
whatever) back from the method (we often do that anyway).
What do you think John, what's your feeling after reading Charles' 
proposal?

Alex

*********************************************************
                       ** Alexander Griekspoor **
*********************************************************
                 The Netherlands Cancer Institute
                 Department of Tumorbiology (H4)
           Plesmanlaan 121, 1066 CX, Amsterdam
                     Tel:  + 31 20 - 512 2023
                     Fax:  + 31 20 - 512 2029
                    AIM: mekentosj at mac.com
                     E-mail: a.griekspoor at nki.nl
                 Web: http://www.mekentosj.com

           LabAssistant - Get your life organized!
           http://www.mekentosj.com/labassistant

*********************************************************




More information about the Biococoa-dev mailing list