[Biococoa-dev] BCSequence class cluster
Koen van der Drift
kvddrift at earthlink.net
Sat Jan 8 07:58:40 EST 2005
On Jan 8, 2005, at 7:45 AM, Alexander Griekspoor wrote:
>> You only need to put the test in the init of the BCTools subclasses.
>> No need to keep them in BCSequence, et al. Another possible solution
>> could be to create a DNATools/ProteinTools class, which has
>> convenience methods to various manipulations only for that type of
>> sequence (this is the BioJava approach - I like the first one better,
>> though).
>
> The comment I had was one I've expressed before that I would strongly
> argue against DNA/ProteinTools for every thinkable manipulation of
> your sequence objects. Although I have to admit I haven't practically
> used BioJava much, one thing that annoyed me in there examples was
> that for even the simplest manipulation of your sequences you have to
> instantiate and use tools. I think tools are the way to go for complex
> things, but for things like reverse and complement I don't wanna think
> of needing tools for that, so un-cocoa like..
I agree, BioJava has a lot of good things, but they use way to many
steps to get things accomplished. But maybe that's inheritant to Java,
which I hardly know (I can only read it), Or maybe when the framework
gets bigger, these things turn out to be useful.
>
>>> To implement mutable objects in the class cluster could be a bit
>>> tricky, because there are two conflicting subclass organizations
>>> here: mutable/immutable and dna/rna/protein/codon. To get all the
>>> combinations, it seems that we need 8 subclasses!!
>>> Oops, Koen won't like this, LOL ;-) On the other hand, look at the
>>> number of NSNumber subclasses...
>>
>> No, I don't like that :D, see my comment above. Another possibility
>> (also stolen from BioJava) is to make a BCToolsEdit class that takes
>> care of editing a immutable class.
>
> Although practically a valid option, again, this sounds weird, I think
> we've clearly made a bad design decision the moment you start editing
> immutable classes ?!
>
Now I think of it, is there a good reason why we should have immutable
sequences? The only I can think of right now is that we have to be
careful when annotations are present. If we can solve that, then IMO
there is no need for both immutable and mutable variants. Charles, you
know perl, any idea how this is solved in BioPerl?
- Koen.
More information about the Biococoa-dev
mailing list