[Biococoa-dev] Using an untyped class sequence

[Charles Parnot]

> > Nice discussion! But indeed the question which hasn't been  
> answered by both
> > pros and contras, can the symbolset provide the error checking  
> and return
> > value customisation to such a level that we don't need the typed  
> sequences.
> > Note that we could provide much of this in the BCSequence methods  
> and I
> > personally think it would be possible, which would give us one  
> unified
> > interface to BCSequence. What do you think? Charles did I now get  
> it right,
> > that you actually are thinking of only the typed versions? What's  
> your
> > viewpoint on this?
>
> There's no question that we're going to have a sequence type  
> maintained somewhere - the question seems to be where. I have no  
> doubt that, although the code would be structured differently,  
> fairly equivalent functionality could be provided by either typed  
> classes or by asking a sequence object what type of sequence it  
> contained.  So, I’m not arguing about either of those aspects.
>
> In my earlier email, though, I provided a list of the advantages of  
> typed sequence classes and some disadvantages of the alternative.   
> Koen had objected to typed sequence classes in the past because we  
> had some code duplications, but with that problem now fixed, I’m  
> not sure whether there are any disadvantages to typed classes.  I  
> haven’t seen an equivalent list of advantages to typed classes.   
> The only thing that’s clear is that other BioX projects have used a  
> single sequence class, but we don’t currently know their reasoning.
>
> So, can anyone sell me on the advantages of a single class?
>
> JT

This is exactly right, John. We are mixing a bit 3 different aspects  
of the typed/untyped issue:
* the public interface: this is what the user and the compiler sees
* the implementation: even with just one public interface, there can  
still be several private subclasses (that would be in the case of a  
real class cluster)
* the runtime: even with several classes, a lot of the code is anyway  
run in the superclass

I do believe than in terms of implementation, the subclass structure  
is better than one class. Of course, it is still important to put as  
much code as possible in the superclass and avoid code duplication,  
which was a very legitimate concern of Koen (and I tried to address  
as much as possible when I cleaned the 'init' methods). John is  
right: this concern has been addressed. If you look at the code now,  
the subclasses are very light, and only contain specific code. The  
subclasses are not completely empty (except BCSequenceProtein at this  
point), and it is a good thing that the specific code goes in a  
specific class: it separates code in a very natural way. We should  
stay vigilant and keep it that way.

(As an aside: The BCSymbolSet mechanism actually helped in the  
process of generalizing the code in the superclas I actually liked  
the whole concept very much, it is quite powerful.)

In terms of the public interface, the other main benefit of  
subclasses is to have compilation check. Of course, this could be  
achieved even if all the code was in just one class, and one would  
create dummy classes for the sole purpose of compilation checking and  
typing.

My bottom line is the following:
* it seems we should keep the subclass structure no matter what; and  
because Koen's concern has been addressed, he might agree with  
that... Koen? ;-)
* several of you want compilation checking, which is a legitimate  
desire, and because these people (John, alex, peter,..?) are REAL  
users of the framework, it would be stupid to not provide it, and I  
certainly would not want to argue against it; if the user wants it,  
it should be there!
* except me, it seems everybody is confused by the placeholder class  
BCSequence; the idea was to try to have both options (BCSequence or  
the bunch of typed sequences), and decide at some point to dump one  
of the two or maybe keep both; it seems the consensus is now to dump  
one of the two, and based on the above, it seems logical to dump  
BCSequence; this is OK, there is very little code in there anyway, it  
was not very much work; just please keep it around a little while, I  
will archive it somewhere on my hard-drive (I don't want to rely only  
on the CVS server!!). And if we ever want to switch back to a single  
public class, it would not be very much work; the existing class  
structure would be easily amenable to a class cluster.

So, ready to move on :-) ?

charles

--
Xgrid-at-Stanford
Help science move fast forward:
http://cmgm.stanford.edu/~cparnot/xgrid-stanford

Charles Parnot
charles.parnot at gmail.com