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

[Lincoln Stein]

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.

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.

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.

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.

Lincoln

On Monday 22 December 2003 03:28 am, Juguang Xiao wrote:
> Hi all,
>
> I was Java programmer learning Perl from Bioperl code. I did learn
> a lot for you ushers. Recently, I decide to read Programming Perl,
> the Perl Bible, and found some common-sense code in bioperl is not
> the best. Here are my findings.
>
> 1) getset
>
> Months ago, Hilmar gave us a tip for the getter/setter to accept
> undef. The code is like
>
> sub name {
> 	my $self=shift;
> 	return $self->{_name} = shift if @_;
> 	return $self->{_name};
> }
>
> It is no fault about it until this super or sub module have a
> method with different name but use the same hash key.  So choosing
> the hash key is not on your own ease. Here is the code in Section
> 12.7
>
> sub name {
>      my $self = shift;
>      my $field = __PACKAGE__ . "::name";
>      if (@_) { $self->{$field} = shift }
>      return $self->{$field};
> }
>
> Your getset generator may need to be updated. ;-)
> ##############################################
> 2) use vars (@ISA);
>
> This is copied from Chapter 31.
>
> 31.21. use vars
>
> use vars qw($frobbed @munge %seen);
>
>
> This pragma, once used to declare a global variable, is now
> somewhat deprecated in favor of the our modifier.  The previous
> declaration  is better accomplished using:
>
> our($frobbed, @munge, %seen);
>
>    or even:
> our $frobbed = "F";
> our @munge = "A" .. $frobbed;
> our %seen = ();
>
> #########################################
> 3) auto getset, again
>
> I really cannot stand individual getset any more, after I read
> Section 12.7. Do yourself a favor, read it, please. One year ago, I
> suggest to use AUTOLOAD replace all getset methods. The idea was
> mercilessly extinguish. Now I have big boss's support in his book.
> Anyone wants to say anything? ;-) ( I do not mean to use AUTOLOAD
> again, but the rest ways in that section should be discussed) Just
> do not stay your Perl wisdom and braveness at high school, though
> your bioinformatics achievement reach above the Ph. D height.
>
> I prefer the idea on Section 12.7.4. Generating Accessors with
> Closures. It is listsub'able.
>
>
> my $0.02
>
> Juguang
>
>
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at portal.open-bio.org
> http://portal.open-bio.org/mailman/listinfo/bioperl-l