[Biococoa-dev] more ramblings

Alexander Griekspoor mek at mekentosj.com
Sat Dec 4 04:04:30 EST 2004


John and Koen,

Op 4-dec-04 om 3:34 heeft John Timmer het volgende geschreven:

>
>>>> Well, a complement doesn't make sense for a protein does it?
>>>
>>> No, it doesn't. That's why I made it such that if you pass it to a
>>> protein, the result will just be an empty sequence. This is actually 
>>> a
>>> good example of  what I mean by putting the convenience methods only
>>> in BCSequence.
>>
>> I know, but again at some point it doesn't make any sense anymore, 
>> than
>> we can just as well get rid of the subclasses if that's where you are
>> pointing at (again ;-). Either we go in your direction and throw
>> everything in one class, or we do it nicely with subclasses. The fact
>> that your complement tool object returns nil if you hand it a protein
>> sequence is very elegant and nice (if that is what you want per se),
>> but I don't see any reason why we are obliged to add the method call 
>> in
>> BCSequence instead of only in the DNA/RNA subclasses. Again, it 
>> doesn't
>> make any sense to add the possibility to call complement on a protein
>> sequence, unless there is only one bcsequence class. And if I'm
>> outnumbered in this opinion, than I even rather switch to the
>> one-BCSequence approach, as now we're ending up in some strange 
>> hybrid.
>> John, I think it's your call...
>
> Well, if it's my call, I'm pretty sure you know where I stand.

Then it perhaps wasn't really fair from the start to ask for your 
opinion, but ok.

> It just
> seems like silliness to me to allow the following:
> Have a method associated with the data it can't possibly act on
> Have a method to be called on sequences that it has no relevance to
> Make it easier to have developers accidentally make stupid mistakes.
>
Yep my point exactly.

> As Alex said, failing with an empty sequence is a relatively elegant 
> way of
> handling the situation.  But  there's absolutely no need for the 
> situation
> to be handled - placing the method into the appropriate subclass (in 
> this
> case the currently non-existent BCSequenceNucleotide, parent of DNA 
> and RNA)
> is just clearer, safer, and more sensible.

It might make a lot of sense to add this class.

>  I just don't see a big benefit -
> the one claimed was preventing duplication of code, but adding the
> appropriate subclass eliminates the duplication.
>
> So my vote is definitely against putting these in BCSequence.  Until 
> there's
> some decision that the subclasses have to be eliminated, we should use 
> them
> appropriately.

Amen

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
                    AIM: mekentosj at mac.com
                     E-mail: a.griekspoor at nki.nl
                 Web: http://www.mekentosj.com

           LabAssistant - Get your life organized!
           http://www.mekentosj.com/labassistant

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


*********************************************************
                     ** 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
                   AIM: mekentosj at mac.com
                  E-mail: a.griekspoor at nki.nl
               Web: http://www.mekentosj.com

               4Peaks - For Peaks, Four Peaks.
        2004 Winner of the Apple Design Awards
                Best Mac OS X Student Product
              http://www.mekentosj.com/4peaks

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




More information about the Biococoa-dev mailing list