[Biococoa-dev] more on BCCodon
Alexander Griekspoor
mek at mekentosj.com
Tue Sep 7 01:35:43 EDT 2004
>> Back online after a food-poisoning on friday (which struck Tom as
>> well, join in for a dinner at our institute's restaurant ;-)
>
> Mosselen?
Luckily not, still not sure what caused it but definitely had to be
removed ;-)
>
> That's a very good explanation for me, and makes things much more
> clearer. So I think this suggestion from Alex would be a good
> solution:
>
> BCSymbol -> BCCodon (with BCCodon having a BCSequenceDNA as member)
> BCSequence -> BCSequenceCodon
Seems I could have waited 5 minutes to let John do the talking ;-)
>>> You don't have to use all methods that are provided by the
>>> superclass, so I don't think it is a problem.
>> Well yes and no, you don't have to use them, but they must return
>> something that makes sense. If you feed a codon in a method that
>> accepts BCSequences in general, it could terribly crash if BCCodon
>> doesn't know how to interpret things.
>
> Why? The abstract method takes care of for instance returning 'nil' in
> such a case. If it isn't implemented in BCCodon, than BCSymbol should
> take care of it with a default response. If you want BCCodon to do
> something else, then just override it.
Sure, but the only point I tried to make that one should be careful
that 1) all superclass methods should be checked to either return
something useful or nil and 2) all classes that work with these methods
should then also expect to receive a nil when they call them.
Although, the latter seems good programming practice, I'm sure there
plenty of examples in my code where things would go terribly wrong if
one of my methods returned nil simply because I know they should never.
>>> Moreover if all classes that deal with sequences use the same method
>>> naming, it becomes much easier for users (and us) to use BioCocoa.
>>> If every class uses a different approach, things get more unclear,
>>> and more difficult to maintain.
>> Exactly my point, but again that doesn't require subclassing per se.
>> Also I was thinking from a user perspective (remember it's a
>> developer here, so code organization is key here) that we can
>> organize things a bit better still, like moving BCCodon to the
>> symbols group, moving the symbols folder to the root instead of
>> inside BCSequence etc. But I'll make a wishlist one of the next days
>> ;-)
>
> Please submit. BioCocoa is still small enough to move stuff around
> (altough it would be less straightforward in CVS ;-)
Ok, well let me first play with CVS a bit then, to at least understand
what I'm doing ;-) I'll let you guys know when I start moving things
around (in a day or two), so everything can be checked back in prior to
that.
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
Windows is a 32-bit patch to a 16-bit shell for an 8-bit
operating system, written for a 4-bit processor by a 2-
bit company without 1 bit of sense.
*********************************************************
*********************************************************
** 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
Claiming that the Macintosh is inferior to Windows
because most people use Windows, is like saying
that all other restaurants serve food that is
inferior to McDonalds
*********************************************************
More information about the Biococoa-dev
mailing list