[Bioperl-l] Re: Automatic generation of set and get methods

[Hilmar Lapp]

> -----Original Message-----
> From: Steven Lembark [mailto:lembark@wrkhors.com]
> Sent: Friday, November 15, 2002 12:17 PM
> To: bioperl-l@bioperl.org
> Subject: RE: [Bioperl-l] Re: Automatic generation of set and 
> get methods
> 
> 
> 
> 
> >>    * Documentation template could be autogenerated
> >
> > Macro does this.
> 
> Only if we insist that everyone use your editor and macro
> set.
> 

It's not my macro. bioperl.lisp comes (has always come) with the distribution. The point I was trying to make is that you could foster consistent code structure of getter/setters by having everybode use a boilerplate macro. The only thing I'd insist on regarding the editor in this scheme is that it be macro-capable.

My main point though is still the same: If people want to use autoload - great, go ahead, do it. Submit code with auto-loaded methods to bioperl - greatly welcomed contribution if it is working code that solves a problem. Noone's going to complain or even change your code to use explicit methods. As for the bioperl core recommendation - my vote is no, discouraged. I personally neither like the style of auto-loading method names, whether this is Java-backwards, Java-infatuated, or plain stupid, nor have I ever found it a problem in my code output efficiency (and yes, I wrote most of my Java separate get/set methods by hand, during the days there were no GUI builders). I personally like to spend my time on solving problems that are indeed problems (to me anyway, or to the one who cuts my paycheck :). 

<snip/>
> 
> The first time a method is called there is a lookup to
> find it. After that the result is cached. Unless someone
> explicitly plays with that portion of the symbol table
> further use of the method is no worse than a subroutine
> call. If an AUTOLOAD installs the method and does a goto
> then the method will be called at full speed from then on.
> 
> Part of Perl's flexability in handling these things is the
> ability to modify the symbol table on the fly. Caching will
> normally save most of this expense. Overuse of AUTLOAD with
> no subroutine installed will be seriously expensive.
> 

I'm a complete ignorant of how the engine runs I have to admit. I made the statement based on Tim Bunce's reviewing our parser and object initialization code and the result basically was that we had far too many method invocations (along with some other things). Once we reduced that the parser in question was ~5-6 times faster.

	-hilmar