[Biococoa-dev] Using an untyped class sequence
charles.parnot at gmail.com
Tue Jul 5 12:32:38 EDT 2005
> > 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
> > 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
> > 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
> > 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?
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
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 :-) ?
Help science move fast forward:
charles.parnot at gmail.com
More information about the Biococoa-dev