[Biococoa-dev] Re: a new design to please everybody (am I pleased?)

[Peter Schols]

Thanks John, this clears some things up for me.
One of the good things about Cocoa - at least for me - is that you need 
very few "checks" when compared to other languages / frameworks. Some 
Java source code I have looked at (I'm not a Java expert) had much more 
checks. I agree that we have to make sure that the framework itself 
takes care of most of the checking (by offering the possibility to have 
errors caught at compile time), so that the code written by users of 
the framework can be as simple as possible.

I was - and I still am - a big proponent of the class cluster approach 
because it would offer the user of the framework a very easy interface. 
I think we would all prefer that the framework would handle all the 
details for us behind the scenes with one, powerful BCSequence class as 
the only interface.
However, now that John convinced me that strong typing is necessary as 
well - or should at least be available for the users who want it - I'm 
not so sure what value the class cluster approach would add. Let me 
explain this: the reason I love the NSString cluster, for example is 
that I don't have to bother choosing between NSSmallString and 
NSLargeMutableString or whatever class I'm actually creating by 
creating an NSString. And that I don't have to do the type checking to 
see whether the particular NSXXXString instance responds to a given 
method. But what would be the point of it if I was forced to check the 
type of NSString the framework created for me (which would expose me to 
the different classes in the cluster anyway)?

In other words, I'd love the class cluster approach with one, 
good-for-all BCSequence class if this were the only interface, just 
like with NSString or NSArray. But what would be the point of having 
the cluster around if we will need to deal with the subclasses (or 
related, more specific classes) anyway. Wouldn't that be an unnecessary 
duplication of the interface users will have to learn, or at least be 
confusing? The point I want to make is: shouldn't we choose one 
approach, in stead of offering two options to the users?

Again, this is just a question I'm asking myself, maybe I'm completely 
wrong. I have never designed a framework before, I just want to help 
out by thinking about this and by asking - possibly stupid - questions 
(and by writing some code as soon as we have taken a decision, of 
course ;-)).

Peter


On 09 Jan 2005, at 15:49, John Timmer wrote:

>
>> I have one question though: if I get it right, the only reason we need
>> the strongly typed approach as an extra option to the good-for-all
>> BCSequence object is that people will get compiler warnings? Or are
>> there additional reasons? To paraphrase Koen, this is an educational
>> question, not a critical one ;-)
>>
>
> As probably the strongest advocate for it, let me give a few reasons:
>
> The compiler warnings are definitely one thing - in practice, they're 
> the
> biggest way I identify when I've been sloppy with my coding before 
> resorting
> to debugging.
>
> Non-typed methods mean that the sequence type has to be checked every 
> time
> the method is called, slowing the code down.
>
> Uncertain return values mean that careful developers will have to 
> surround
> every method call with tests (did it return nil?  Was the returned 
> sequence
> length 0?) that slow the code down and are very tedious to constantly
> implement.
>
> How are we going to define a sensible return value for a method call 
> that
> makes no sense in the first place?  Is nil appropriate?  Throwing an
> exception?
>
> With typed classes, methods could actually be grouped with the data 
> they
> could operate on, instead of in with data they may or may not operate 
> on.
>
> At 4 non-abstract classes to represent all sequences, I hadn't thought 
> the
> structure was that bad.
>
> What is the advantage of allowing something that makes no biological 
> sense
> (ie - complementing a protein)?
>
>
> I'm sure I could think of more were I not a bit foggy headed from cold
> medication.  It just feels like we're twisting the biology in order to
> achieve code elegance.
>
> And I'm not even certain we're achieving that - it feels like the 
> equivalent
> of getting rid of all of the UI control classes in order to achieve 
> the code
> purity of only interacting with NSViews.  A button responds to 
> different
> things and conveys different information than a slider does - they're
> different classes.  The same could be said for a protein and a DNA 
> sequence
> - why treat them like they're the same class?
>
> Although the class cluster idea is very appealing on an intellectual 
> level,
> it's going to take some extra work to implement it in such a way that 
> users
> (again, meaning non-contributing developers) will be able to grasp it
> easily.  And the internal structure is probably going to be extremely
> confusing to anyone downloading the source for the first time.  Given 
> that,
> I'm just wondering whether it's going to be more effort than it's 
> worth.  As
> someone noted a few mails ago, it's going to require extensive
> documentation, and the assumption that developers are any better about
> reading the documentation than regular users are.
>
>
>
> As an aside, I was struck by the following quote from Charles:
>> 2. Oups, BCSequenceProtein.h does also import BCSequence.h, so the 
>> compiler
>> thinks that BCSequenceProtein can respond to '-complement'. Well, and 
>> all the
>> methods. So much for a strongly-typed sequence class!! What do I do??
>>
>> OK, I remove -complement from the BCSequence.h header, and only put 
>> it in
>> BCSequenceDNA.h, but not in BCSequenceProtein.h
>>
>> 3. Aïe, now BCSequence gets some compiler warnings when trying to use
>> -complement. How do I prevent that??
> Item 3 is the whole point - it's a good thing, not something that 
> needs to
> be prevented ;).
>
>
> _______________________________________________
> This mind intentionally left blank
>
>
> _______________________________________________
> Biococoa-dev mailing list
> Biococoa-dev at bioinformatics.org
> https://bioinformatics.org/mailman/listinfo/biococoa-dev
>