[BioRuby] Bioruby design

[Pjotr Prins]

Thanks for the reply Naohisa. As we are moving on to design, rather
than one implementation I am changing the thread.

On Mon, Jan 04, 2010 at 04:15:18PM +0900, Naohisa GOTO wrote:
> It is safe not to merge bioruby internal options and PAML's options.
> If the upstream authors of PAML introduced a new option named binary,
> severe problem would occur.

I am against breaking interfaces. This is a minor design problem
which should be avoided in the future. And, yes, I would certainly
not favour a polymorphism solution, unless unavoidable. 

I don't think it is worth 'fixing' this interface aspect at this stage. 

Perhaps, there will be opportunities later.

> Note that Ruby's author Matz has said that he had not applied the
> principle of least surprise to the design of Ruby.
> (http://en.wikipedia.org/wiki/Ruby_(programming_language)#Philosophy )
> Please be careful that the word "principle of least surprise (POLS)"
> is NG word when you request something in Ruby.
> (http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/26942 )

I did not know that, and personally I do not care. I think POLS is a
really good idea, though it should not automatically come at the
expense of (for example) convenience, or performance. I favour easy
API's, and that is where the principle of least surprise comes in. It
means to me that I don't have to fetch the manuals every time (like I
do with Perl). So, let's not throw away the baby with the bath water.

I like POLS, as much as I like KISS.

> > >> report.models[0].name
> > => "M0"
> 
> I suppose report.models returns a Hash containing objects of newly written
> class (for example, Bio::PAML::Codeml::Report::Model) or Struct.
> It seems good.

In fact, I have made it an array. See my PAML branch.

> >  runner.rb --test-dependencies
> 
> I'm now searching ways to pass such parameters to tests.

In the runner you can parse the parameters first and pull them off
the stack. I did something like that for cfruby:

  http://cfruby.rubyforge.org/git?p=cfruby.git;a=blob;f=test/runner.rb;h=c202e48783a744c4cb3e339e2b891b3eab354c3e;hb=HEAD

 
> I'd like to keep tests simple and clear, and I think using standard
> File.read is enough and clearer. When using such special class, to know
> the behavior of the test code, reading extra file is needed.

I disagree, but that is obvious. 

> > Personally, I dislike the naming/name space scheme of Bioruby.
> > What to think of invoking a class named
> >
> >  report = Bio::PAML::Codeml::Report.new
> 
> Because there are many bioinformatics software and databases, names
> tends to be longer, and nesting of namespace tends to be deeper.
> I'd like to know naming rules and policies of other open-bio projects.

I think we should not mirror ourselves on these. We can do better.
RoR is a much better example to mirror ourselves on.

> > Why can't it just be
> >
> >  include Bio
> >  report = Codeml.new
> 
> I think it is enough to write "include Bio::PAML" instead of (or in
> addition to) "include Bio".

Not really. It brings in another source of errors for users if they
have to think about that context every time. We will get all
variants, like Bio::Kegg, Bio::Sequence etc.

I think name spaces are there to *avoid* conflict. If a naming scheme
precludes conflict, why bring in another layer?

I want Bioruby to be as easy as possible, and with the least
amount of typing. More text = harder to read.

> >  include Bio
> >  result = Paml.new(:program => 'codeml')
> 
> I don't like introducing such new parameter like :program.
> I think 1 class 1 binary is better.

I agree. It was just another option.

> In addition, because the differences within PAML tools (codeml, baseml,
> yn00, etc.) are currently not small, merging the classes is not so
> realistic now.

We have to separate our own conveniences from design choices.

Meanwhile I do agree we should not change the current interfaces. We
can create a new version of Bioruby with both old and new interfaces
supported. That is one thing I propose.

I am putting together a discussion document on the future of Bioruby
(design choices). We will have opportunity to discuss that in Japan.
We can consider raising a community vote once we have a list of
options.

Pj.