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

[Alexander Griekspoor]

Peter sums up my feelings perfectly:

> 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?

Absolutely! I'm definitely in favor of this brilliant one-does-it-all 
BCSequence class, but the moment we're moving into the situation where 
you're using the subclasses in the end, there's no use to go in that 
direction IMHO. I think we should choose either way.

> 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 ;-)).
Same here!
Alex


>
> 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
>>
>
> _______________________________________________
> Biococoa-dev mailing list
> Biococoa-dev at bioinformatics.org
> https://bioinformatics.org/mailman/listinfo/biococoa-dev
>
>
*********************************************************
                     ** 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.

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