[Biococoa-dev] Base design

[Alexander Griekspoor]

> The basic ideas are two-fold:  convenience and readable code.  For
> convenience, I've created a sort of "super-header", 
> BCSequenceDNABases.h.
> Importing this will in turn import all the individual base headers.
Ok, got it now, that seems a good idea.

> Given that I have to put methods there, I think I'm going to move all 
> the
> singleton generation methods into the base class.  I think (though I'm 
> not
> positive), that it'll be simpler to call
> [BCSequenceDNABase adenine];
> [BCSequenceDNABase thymidine];
>
> Than having to call a different class for each base.
I agree, that sounds really simple and elegant

> I should have an example coded with ATCGN before the end of the day, at
> which point it'll be easier for you to tell me what I've done wrong ;).

Great! Looking forward to that John!


> Yes, I did receive it, I'm just not convinced ;).  I just think that 
> atomic
> vs. ambiguous is a bit of a false distinction.  95% of the time, for 
> coding
> convenience, you're going to want the two types of base to behave
> identically - by this I mean that it's easier to have both types 
> respond to
> the same selectors so that loops can just plow through an entire 
> sequence
> without checking what base it's dealing with.

> A lot of the remaining 5% mostly encompasses testing whether it 
> belongs to
> atomic or ambiguous, which a single method will handle.

The nice thing of two classes is that you can add specific behaviour in 
the ambigious one, and have the superclass contain all shared methods 
(which still allows most methods to plow through the complete sequence 
as the methods they rely one are inherited from the BCSymbol class). 
Still, the question really is "how many methods are there to put extra 
in?". If you look at BioJava I couldn't find any that quickly, so I 
guess you are right and that would not justify more complexity compared 
to one method like (BOOL)isAmbiguous; In fact if you do (NSArray 
*)getMatches; and it returns more than one you know already, but a 
boolean convenience method is well really convenient ;-)
I guess it's a matter of taste in the end, and maybe there isn't a "one 
is better then the other" here.

> If you could convince me otherwise (you have in the past - witness the 
> fact
> that I'm writing base classes at all), i'll happily reconsider.
Unless somebody else has a reason why two classes would be better then 
one, I'm not gonna.

> PS - Overall, I think a lot of things in BioJava are great, since a 
> lot of
> bright people have put serious thought into these things, but Java is a
> statically typed language, and there's going to be some differences 
> based on
> ObjC's flexibility.  There's also going to be differences because the
> foundation toolset makes different things easier in Cocoa than in Java.

You're absolutely right, it's essential to leverage the advantage of 
Cocoa over those of Java, but it's nice to have a source of inspiration 
at hand.

> The key thing will be recognizing when I'm doing things differently 
> just for the
> sake of being different, so let me know if you think I'm doing that.
That's the nice thing of being with more than one ;-)
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

MacOS X: The power of UNIX with the simplicity of the Mac

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