[Biophp-dev] Task oriented design approach (was: comments on CVS, XML, and other TLA's)

[Greg Tyrelle]

*** mail-lists+biophpdev@dogphilosophy.net wrote: 
  |My continued chanting of "task oriented" just refers to my thought that
  |when deciding what to write and how to design it, one should ALWAYS 
  |(at least for this project) start with a "real-world" task, RATHER THAN
  |a "capability.

I would argue instead for building "task" based modules on top of
modules that provide "generic capabilities".

But from a user point of view "tasks" make more sense. I'll try and
elaborate...

  |The thinking behind this is that modules, as soon as they can "do" ANYTHING,
  |they can do something immediately useful for a "real-world" task - this also
  |guides what "parts" of a module to start with (i.e. in this example, doing
  |anything special to deal with other-than-PubMed can be left out of the
  |0.0.01 release, and dealing with the other data types gets added as "tasks"
  |come up that use them.)  In short, modules then get designed and released
  |in smaller sets of changes but with always-useful-for-"real"-tasks features
  |being added...

Hmm...

You need to have certain generic capabilities to build up useful "real
task features".  I'll assume that you point with "real task features"
is to make the modules as "useful as possible" out of the box for the
end user ? If this is the case then the following example (obvious
given my recent efforts) might illustrate what I'm getting at:

class ESearchClient {

    function esearch($database, $term, ...) {

        // check to see if the query is in cache

        if ($this->_check_cache($term)) {
            return $this->_get_cache($term);
        } else {
            // do the actual query
        }
    }
}

This class gives you your "generic capability" which you can then
extend to specific tasks:

class PubMed extends ESearchClient {

    function search_ids($term) {
        return $this->esearch("pubmed", $term);
    }

    function search_abstracts($term) {
        $ids = $this->esearch("pubmed", $term);
        return $this->efetch("pubmed", $ids);
    }
}

When using the "PubMed" module the details of parsing, querying,
caching of the EUtils interfaces are hidden. If I'm understanding you
correctly then the final outcome here is "task oriented" ?

$pubmed = new PubMed;

$ids = $pubmed->search_ids("bioinformatics");

Of course it doesn't have to be OO (a wrapper class maybe ?) and the
final PubMed interface could directly return abstracts etc.

$abstracts = $pubmed->search_abstracts("bioinformatics");

Can this logic be applied to other "capabilities" and "tasks" in
BioPHP or does this fall down in certain circumstances ? 

  |> Personally I would find a "BioPHP proposal" document a better starting
  |> point to work from if you want to discuss design issues ? For example
  |> a comparison of how the various Bio* projects are structuring their
  |> modules/interfaces might be useful ?
  |
  |I have thus far not concerned myself with looking TOO deep at other BioXXXX
  |project's capabilities (other than to get a general "feel" for what they can
  |/are designed to do), because I don't consider 'do the same thing as 
  |BioPerl/Python/Lisp/Ruby/Java' to be a valid "task". :-)

Sure, but learning from others mistakes is generally considered
wise. As is not reinventing the wheel :)

For example Bioperl splits "capabilities" and "tasks" into
Bio::ModuleName and Bio::Tools::ModuleName::run IIRC ? Also their
SeqIO, SearchIO interfaces are quite "task oriented".

  |Even if I can technically call this "my" project at the moment (at least until
  |there are "formally listed" other developers, which will be Real Soon Now, I
  |suspect), I'm really not a "rule with an iron fist" kind of guy :-) Therefore,
  |as people convince me by rational argument that I'm being an idiot, I will be
  |changing my opinions...

Understood.

Projects and the underlying ideas behind them evolve. So I expect to
have my design ideas challenged (with rational argument) when
interacting with other people. It is part of the development process
and what makes it interesting :)

_greg

-- 
Greg Tyrelle  (http://www.kinglab.unsw.edu.au/~greg)

"Logic only gives man what he needs, 
 magic gives man what he wants" - Tom Robbins