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

[Juguang Xiao]

On Monday, December 22, 2003, at 10:57  pm, Lincoln Stein wrote:

> Hi Juguang,
>
> A lot of people are going to be offended at your way of giving advice.
> Do not get upset if you are flamed.  Your advice is good in many
> ways, but your manner of presenting it is poor.  Nobody likes being
> compared to a high school student, particularly those of us in
> bioperl who *are* high school students.

Hi Lincoln,

I respect each developer of bioperl, as I am one of them. Sorry for my 
impolite manner.

> The bioperl core developers are aware that much of the current
> framework should be discarded in favor of more sophisticated class
> definition systems, such as Class::Accessor.  However, there are also
> significant downsides to these systems that need to be discussed in
> detail. A big problem in using any autoloader-based accessor system
> is that the UNIVERSAL::can() method will no longer work properly on
> autoloaded methods.  There are also performance penalties.

As in my previous reply, this is no performance penalty in that method, 
since it takes place at compile time. Sorry again to mislead you 
remember AUTOLOAD.

> Something that authors of the Perl Bible and other didactic texts seem
> to miss is that for better or worse Perl is fundamentally unlike
> Java.  With Java, one mujst assume that the superclass acts like a
> black box and subclasses have no knowledge of its internals.  Perl is
> much more informal, since the internal workings of the superclass are
> always exposed in both source code form and in subclass-visible data
> structures.  Yes, it's not terrific style to use hash keys that might
> inadvertently be overwritten by subclasses, but it isn't a fatal
> error either. It is relatively easy to see the conflict and fix it. I
> cannot think of a case in which a persistent Bioperl bug turned out
> to be due to an inadvertently overwritten instance variable.

No, there is no bug because of it, ... so far.

> A bigger issue is that changes to the accessors is relatively minor
> compared to a long overdue overhaul of the architecture and
> underlying data model of the sequence and sequence feature classes.
> This is a big and important job.  Please don't focus on the trees and
> miss the forest.

The coders are at their own ease and risk to have the suggested way in 
the own package. Architecture is not bothered at all, I think. Well, my 
experience may be shallow, however, I am in favor of central control, 
which also means high reusability in some sense. If we can have some 
smart shortcut for generate and *maintain* the cheap accessors, then we 
will have more time with our biological logic code. That is my hope.

Thanks for guidance from all you guys this year. Merry Christmas!

Juguang