[Biophp-dev] Bioinformatics.org's PHP

[biophp-dev@bioinformatics.org]

On Wednesday 09 April 2003 09:54 pm, Dong Gregorio wrote:
> Yes, I guess we should Greg's advice and have folders for each
> developer alongside a shared folder.  Later on, we can move to
> integrate our works.

Sounds good - it looks like all I need to do is add someone's
Bioinformatics.org login name to the list of developers to grant
access to CVS.

> Better than most of 'em, I'd say!  Well, one advantage of PHP over
> say Perl is that PHP is a lot easier to learn and the code is a lot
> readable.  I do not want to start a "religious war" of languages
> here, but whoever said that Perl is a write-once language should
> be canonized a saint/prophet.
>
> By the way, this is coming from someone who knows Perl too.  =)
>
> Database access in PHP is a breeze compared to Java's clumsy
> jdbc::yourdatabase::etc URL string, which gave me a lot of
> headache.  =)

True - one of the things I really LIKE about PHP is that it is much
easier to follow and understand than Perl can be because it is a bit
less "wild", without going to the extreme of "bondage and discipline" that
Python seems to go to in order to "enforce the one true way to properly write
programs".  At the same time it retains nearly all of the capability with
text parsing that Perl does.  And, yes, the database access utterly
beautiful, in my opinion.

But of course, none of this is DEPENDENT on being run from a web server :-)

> To cite two examples, PHP4 does not support data protection.
> You can get/set class properties without going through any
> get/set methods you might have written.
>
> Another limitation is that PHP4 does not support multiple
> inheritance.  I originally wanted to try a setup where a
> Sequence class was a child class of BOTH the NUCLEIC ACID
> class and the PROTEIN CLASS, but couldn't do it.

I knew about the first one - I actually do intentionally put data
retrieval and modification methods in my PHP classes simply because
one's not supposed to have a reason to directly fiddle with
the variables inside the class.

I have a rough understanding of multiple inheritance, but as, 
I'm afraid, all of my real OO experience comes from PHP so far
(The Horror!) I haven't gotten deep into that.  One of these days
I really need to get deeper into Java, but just haven't had
time yet...

> While I am no die-hard OO person (sometimes the OO hierarchy
> can get ridiculously complicated like your DOG::ACTIVITY::
> SINGING::SONGPARSER::XML or UNIVERSE::MILKY WAY GALAXY::
> SOLAR SYSTEM::EARTH::USA::IDAHO::YOURSTREET::YOURDRIVEWAY),
> OO has its advantages (code reuse, easier maintenance) and
> I look forward to seeing stronger OO features in PHP5.

My initial attraction to OO in PHP come from both of those, but
particularly from the fact that it becomes easy to create a "black box"
that someone with even a rudimentary knowledge of PHP (which is a quite
easy level of knowledge to achieve in PHP - more so than most other
languages I think) can incorporate them with just a little "glue" code
to accomplish more useful things.

One might, for example, want to take a sequence from a cultured unknown
organism and, say, do a BLAST query to determine the Genus and closest
species match possible, retrieve some taxonomy information and sequences
from several of the matches, combine that information with an existing
multiple alignment (built from previous analyses), and then finally 
incorporate those sequences into an existing phylogenetic tree.  My intention
is that with BioPHP modules, this'll (eventually) be easy with a bit of
"glue" code to string together the results of the blast query from the
blast query module, combining the new sequences plus the existing ones
into a sequence list, exporting from the sequence list to Clustalw and
retrieving the results, exporting the results in Phylip form and passing
them off to, say fastDNAml via an appropriate frontend...

> >It's that specific idea that makes me so intrigued about PHP's >support
> > for access to Java classes, and the possibility of >a "BioJavaPHP" (Doo
> > dah, doo dah) sub-project
>
> Or a BioPerlPHP or a BioPythonPHP perhaps?  BioCobolPHP?

Well, no, not Perl or Python - the point of a hypothetical "BioJavaPHP"
would be the easy integration/embedding of "compiled" modules, in a
"native" manner, seamlessly into PHP, so embedding other interpreted
languages wouldn't really get us much.

Hmmmm...COBOL is compiled, isn't it?.... :-)

> Hahaha... sorry, I thought there was only ONE PHP WAY in Redmond.

Nah, Redmond wouldn't allow it, though I'm sure they have a "ONE VB WAY"
somewhere :-)

> Ah yes, now we go the topic of human-computer interface (just
> a fancy term for "how the hell are people gonna use BioPHP?")
>
> Since you and Greg have more bio experience than I do, I would
> like to know how bio people would use BioPHP, as you see it.
>
> Perhaps you can come up with a list like this:
>
>    1) To search for bio data from a variety of sources using
>       one interface/web page; (ONLINE)
>
>    2) To write custom-made algorithms for sequence alignment,
>       gene prediction, etc. (OFFLINE)
>
>    3) To be a teaching aid/tool for people who want to learn
>       bioinformatics. (ONLINE/OFFLINE)
>
> Et cetera, et cetera.  The list would be a significant input
> into the design of BioPHP.  How about it guys?

Ah, now we're into another area that I've been particularly interested
in getting other people's opinions on...

My PERSONAL thoughts on this include things like:

-Search for, retrieve, collate, and convert data from various sources, 
especially (but not ONLY) online ones.

-Provide easy-to-use modules, designed so as to be as easy and intuitive
to "operate" (this includes having the "end-programmer" modules not 
being too excessively split up - either by incorporating as much functionality
as can reasonably be done into individual classes or by having "wrapper"
classes.)

-Design with the increasingly popular command-line (which would include, for
example, PHP-GTK) usage of PHP in mind, but without "tying" the modules
to command-line use (i.e. the modules should be "at home" both on the CLI
as well as directly include-able in a web-based script).  This means
that it will be feasible to write standalone GUI bioinformatics
applications in PHP using either PHP-GTK or PHP's optional Java support
without having to re-write "special" versions of the modules (as WELL 
as being able to use the modules unchanged in the more traditional
web-based framework).

-As a teaching "environment" to allow PHP developers to learn about
real-world bioinformatics applications, to allow bioinformaticists to
learn PHP, and in general to promote "wider" application of PHP.

-(Secondarily and selfishly, to give ME an environment to improve my
overall knowledge of "proper" programming technique (especially as relates
to OO design), further and broader experience in PHP itself, eventual
experience with Java [as a "backend"], experience in XML, broader
experience in Bioinformatics in general, etc.)

There's a start anyway...