[Biococoa-dev] Sequence Structure

[Alexander Griekspoor]

On 11-jul-2005, at 17:04, John Timmer wrote:

>> [snip]
>
> Well, it's not just that.  Untyped sequences make the sequences  
> stupid -
> they don't know what they are, they don't know what operations they  
> can
> perform, and they have to have defined responses to cope with  
> requests for
> operations they can't perform.
They DO know who they are, their symbolset tells them, and they adapt  
their behaviour based on this.

> Essential methods get scattered in a ton of other classes (mostly  
> tools, but there's going to be a lot of tools in the
> end) - you need to call through to a separate class just to figure  
> out what
> type of sequence you have, and something as simple as complementing a
> nucleotide sequence requires the creation of a new object and may call
> through about 4 different methods there (which is what I hate about  
> BioJava,
> as we've discussed).  And yes, I hate having to test the sequence  
> type every
> time I think about doing anything with the sequence.
Well, you don't have to because we do that inside the bcsequence  
object, you can call complement on a sequence and it will do the  
check if given the assigned symbolset it would make sense to return a  
value, nil or throw an exception. you don't have to do anything.

> If I create a nucleotide sequence, I want it to act like one.
It will because you have created a nucleotide sequence the moment you  
assign a nucleotide symbolset to the sequence. and it will behave as  
one.
>
>> John, I am sure I speak for the others too that I would hate to  
>> see you
>> leave, so again, we should try all our efforts to come to a good way
>> out of this.
>>
>
> I seem to be doing my best thinking on the subway these days - on the
> commute in, I thought about how to possibly handle this, and here's a
> potential solution:
>
> We do create a lightweight, high performance sequence object that's  
> untyped.
> Basically, it acts as a specialized NSArray for sequences.  The  
> tools focus
> on working with this object, since they will be performing the  
> processor
> intensive operations, and this is designed for performance.  I  
> rework the
> existing sequence subclasses to be holders for this.  Convenience  
> calls
> through to the tools put a "smart" interface on the otherwise stupid
> sequence object.
>
> This is not ideal, as it creates a lot more call-throughs to  
> another class.
> That's not such a problem, though, as most of those call-throughs  
> would have
> gone to NSArray or tool classes in the current structure anyway.   
> It also
> creates design decisions - when a file is read, does it create a  
> sequence or
> a typed sequence holder?  Should we create methods to do both?   
> What about
> annotated sequences - should they hold one or both types of sequence
> objects?  Fortunately, the option of creating the appropriate type of
> sequence object on the fly should let us keep both around, as needed.

This is an interesting solution, indeed a kind of custom NSArray for  
sequences would make sense, and would be a solution, but as you said  
this will certainly require a tool for everything right? And how does  
it handle the mutable vs immutable PLUS different subclasses for  
protein, dna etc?
>
>
> Regardless, in the end, I'm not threatening to no longer contribute  
> - my
> focus would just change based on which things I would find most  
> useful.  The
> sequence classes would no longer be useful, but I'm certain there  
> are still
> things in the framework that I'd like to use in future projects.

That's great news John, thanks!
Cheers,
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
                   E-mail: a.griekspoor at nki.nl
             AIM: mekentosj at mac.com
               Web: http://www.mekentosj.com

                  EnzymeX - To cut or not to cut
              http://www.mekentosj.com/enzymex

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.bioinformatics.org/pipermail/biococoa-dev/attachments/20050711/f60ec1a1/attachment.html>