Subject: [Biococoa-dev] New Structure for BioCocoa part II

Koen van der Drift kvddrift at
Sun Jul 3 13:14:23 EDT 2005

On Jul 3, 2005, at 8:52 AM, Philipp Seibel wrote:

> Hey Alex,
> nice to hear something from the netherlands :-).
> Am 03.07.2005 um 13:46 schrieb Alexander Griekspoor:
>> - The class cluster design of sequence objects. Is it still 
>> necessary, is it correct, flexible? As said, phil and I had problems 
>> with it, and phil was not sure if it was implemented fully correct, 
>> but he'll chime in I guess
> There is a structural failure in our implementation, the user thinks 
> he will get a BCSequence object, when he calls a init or convenient 
> method of BCSequence, but he gets a BCAbstractSequence. So we have to 
> fix the inheritance model.
>> . Purely from complexity towards novel users (and people like me who 
>> had to get back in again ;-), I would like to see it disappear if 
>> possible.
> thanks for mention the class cluster problem. Here is a short 
> description of my understanding of a class cluster:
> A class cluster like NSNumber is intransparent to the user of the 
> framework. The user just knows the NSNumber class, but the 
> functionality and content of the class depends on the constructor and 
> initialization of the class. NSDoubleNumber, NSIntegerNumber etc have 
> all private headers, so the user doesn't know the class exists.
> ---> In our implementation is all visible to the user... (public 
> headers for BCSequenceProtein etc.)
> I think we should go for a simple superclass class structure not to 
> confuse the users of the framework.

It's even confusing to us too, there are still places that directly 
call BCSequenceDNA, BCSequenceProtein, etc. I've said it before, but I 
think there should only one sequence class, no matter what type of 
sequence type we are dealing with. How we implement the different 
sequence types is open for discussion. A class cluster is fine, but 
then all headers should be private as Phil mentiones above. I guess 
this is a good time to revive this discussion. Most of you know my 
personal preference (the BioJava approach), but other solutions can 
also be very usable.


- Koen.

More information about the Biococoa-dev mailing list