[Biococoa-dev] more ramblings

[Koen van der Drift]

> Again, although certainly a possibility, sometimes there are 
> alternatives just as good. For example, the thing that I immediately 
> thought after reading:
>> An advantage is that when you ever decide to change the way a 
>> sequence is created, or introduce a new type of sequence, you only 
>> have to modify the code once in the factory, not in each readXXX 
>> method.
> was "Why not do the type checking/bcsequence subclass creation in one 
> method inside the current implementation?"
> We don't check the type in each readXXX method either, so one method 
> like "determineSequenceType" or "sequenceObjectForFile" would also 
> allow you to keep all "factory" methods centralized and easy to change 
> right?

Right. See my other post, IMO a readXXX file should only parse the 
input, and then pass on the requested info to a class that creates a 
sequence.

>> Please do so, but leave the BCFindSequence code as an alternative :)
> Nope, let's choose!  We should all agree on one way again IMHO, we can 
> provide convenience methods, but not two completely separate things 
> please.

No, you're right. I vote for separate wrappers combined with 
convenience methods.

> As you might have understood (boy I almost sound like Steve Balmer 
> with his developers, developers, developers!!), I'm a great fan of 
> convenience methods (convenience, convenience, convenience!!).

I hope for your collegues you don't sweat that much ;-)


> Please provide two methods, one detailed, the other simple and 
> convenient.
> 1 myMethodDoesThis:  withThisAsAnArgument: andThisAsAnArgument etc
> 2 myMethodDoesThis (with default arguments).
> One of the things I absolutely love in the Cocoa frameworks.

That's very nice indeed.

> I think it all comes down to how to describe the border or guidelines 
> of when to choose for internal or external methods. My gut feeling 
> says, hardcoded properties, "one liner" calculations, and trivial 
> methods can be done internally. Also speed is an issue, if it takes 
> time to calculate things it's way nicer to provide a wrapper object 
> because that allows to go for threading, asynchronous methods, and 
> progress monitoring very elegantly. Things like length, is so easy to 
> calculate (a typical one-liner) that it would be ridiculous to have a 
> helper calculate that.

I agree, but let's then focus on having these one-liners in BCSequence 
only, not in the subclasses.


> I would say properties and representations inside, conversions, 
> calculations, and manipulations outside.

Sounds good to me.


> Right so a BCSequence should have a GC% method or MW method or 
> something alike for example right? So we add what the favorite thing 
> what everyone would love to see (in the superclass if it's a general 
> thing (in the case for MW, and not for GC%)):
> [mySequence gcPercentage] or [mySequence molecularWeight] (purely 
> hypothetical).

I'd say in the superclass only. We can have the wrappers test if it is 
the appropriate sequencetype.

Guys, I'm glad the mailinglist is back alive. We're having some good 
and very useful discussions.


- Koen.