[Biococoa-dev] BCSequence class cluster

[John Timmer]

Hi all -

Let me add my happy new year wishes to everyone as well.  I've followed this
discussion as carefully as I could, given a ton of scientific writing I've
got to do (plus a side programming project related to the digital camera I
got for christmas).  I think it might be useful for me to try to summarize
what I think I understand and add a comment or two, and then let you guys
tell me where I'm wrong -

For the purposes of discussion, I'm going to use "users" to mean "developers
using the framework, but not working on its implementation" and "developers"
to mean us.


A class cluster is a potentially good thing, in that it would hide some of
the complexity of the implementation from users.  It doesn't necessarily
make Koen happier, since we may well have all the current classes used
internally.  As far as I can tell, though, nothing short of me getting
around to implementing BCSequenceNucleotide would solve Koen's biggest
gripe, the duplication of three methods in the DNA and RNA subclasses.

We could still make Alex and I happy by defining protocols for sequence
sub-types, and use them in the methods that act on specific sequence types,
like complementation and hydrophobicity.  This way, errors can still be
thrown at compile time, instead of taking the app down at runtime.

None of us have ever done this, so we'd kindof be making it up as we go
along.

Is that about right?

 
Now, for some comments:
My wife's out of town this weekend and I'm sick of reading my own writing,
so I may actually implement BCSequenceNucleotide on Sunday.

Since only the headers are going to be clearly visible to users, could we
make sure that there are comments in the header that indicate if a method is
a convenience call through to a different class and, if so, what class to
find the critical method in.

Now, for the important comment:  I think for major design issues like this,
we could do worse than look at how Apple implements things.  I went to a
Tiger Tech Talk recently, and it's clear that the folks working there put a
tremendous amount of thought into design, and in some cases plan designs to
account for technology that's over a year away from being implemented.

Given that, it may be useful to look at where Apple uses class clusters.  As
far as I can tell, they use them only in situations where there are multiple
Core Foundation objects that they want to provide a single, simple object
oriented wrapper that hides the implementations from ObjC users.  The
primary advantage of this seems to be that it allows the class to swap the
CF objects that hold the actual data as needed without the user being
bothered with the implementation.

I don't think that we have an analogous situation here, though I'm not
positive about that.  Given that, I think we should proceed with caution,
and perhaps ask Apple's Cocoa Dev list for their opinions on when to use a
class cluster.

Okay, better go check my plates - Cheers,

John

_______________________________________________
This mind intentionally left blank