[Bioperl-l] some not-so-good perl practice in bioperl

[Chris Mungall]

This seems to come up quite frequently on the list, and offline in
various discussions between bioperl developers. What follows is my summary
of these dicussions (seeing as this comes up a lot, should we think about
putting this into the FAQ?)

The consensus is that bioperl should be consistent, and employ consistent
styles throughout modules. It would be disastrous if there was a mixture
of both explicit get-setters and a hodge-podge of different AUTOLOAD
conventions.

bioperl developers seem to be (religiously?) divided over using AUTOLOAD
for accessors.  I'd say the majority of those that contribute most to
bioperl prefer explicit accessor methods; they feel that explicit method
definitions means easier-to-understand code.

Then there are those of us for whom the multitude of explicit getsetters
(and accompanying POD docs) in perl is the programming equivalent of
fingernails scratching a blackboard, both anti-perl and anti every
principle we hold dear in programming such as high-level declarative
*compact* code and data representations, accessor methods that type-check
consistently, and eliminating repetition/redundancy. However, such
delicate aesthetics are often a barrier to producing vast and enormously
useful modules such as bioperl.

Nevertheless, we feel we have a point, and the difficulties many new users
have in grokking the large and complex bioperl OM backs us up, IMHO.
However, the way to proceed is neither to harangue busy coders who
have better things to do, nor to introduce AUTOLOADed declarative data
representation formalisms in a piecemeal or ad-hoc way.

This has to be a seperate pilot project, along the lines of what was
suggested by Aaron Mackey and Nat Goodman. I don't think we have a clear
idea of what this would be yet. It may use something like
Class::MethodMaker, which is extremely nice, but could perhaps be extended
even further. Class::Contract is extremely powerful, and borrows features
from proper, well-designed OO languages; unfortunately, C::C is more of a
showpiece module and isn't very practical. Perhaps some merger of the two?
I think we'll be slightly hampered here until there is a clear technical
solution we can consistently use; but it is definitely worthwhile taking
our time and proceeding carefully with the best AUTOLOAD solution.

Ideally someone should be able to grok the majority of the bioperl OM by
scrolling through a few pages of ascii text using a compact declarative
representation.

Many of us are interested in this parallel project, with a view to winning
over the AUTOLOAD skeptics and forming the basis of bioperl-2.x, but this
is only going to happen if we get coding. Moaning (or patronising) on the
list about the existing codebase achieves nothing other than annoying
people.

Cheers
Chris

On Mon, 22 Dec 2003, Ewan Birney wrote:

>
> > You had big boss' support at that time already. My stance on that is
> > unchanged: I can't see how auto-loaded getter/setters make the code any
> > better or increase coding productivity in any way. Especially once
> > you're debugging. If you can't stand individual (uhm - in fact
> > auto-generated by emacs lisp macros BTW) getter/setters then use
> > auto-loading in your code, but don't be surprised if someone goes in
> > and changes it to getter/setters for code clarity and better debugging.
>
> Same here. I think AUTOLOAD should be used v. sparingly. It simply doesn't
> help readability, stability or speed.
>
> emacs macros much better ;)
>
>
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at portal.open-bio.org
> http://portal.open-bio.org/mailman/listinfo/bioperl-l
>