[Bioperl-l] Re: Automatic generation of set and get methods
Fri, 15 Nov 2002 18:46:36 -0800 (PST)
--- Hilmar Lapp <firstname.lastname@example.org> wrote:
> > -----Original Message-----
> > From: Steve Chervitz [mailto:email@example.com]
> > Sent: Thursday, November 14, 2002 11:53 PM
> > To: Hilmar Lapp; Lincoln Stein; firstname.lastname@example.org
> > Cc: email@example.com; firstname.lastname@example.org; email@example.com
> > Subject: RE: [Bioperl-l] Re: Automatic generation of set and
> > get methods
> > [ snip ]
> > Advantages of accessor autogeneration:
> > * Frees developer from drudgery of writing routine accessor code
> For me this is a click on the bioperl-menu and then menu item 'bioperl field
> method.' Boom - the method fully implemented with documentation template
> generated is right there in my code with two mouse clicks (there's a
> keystroke combination too which I keep forgetting).
> If you're not using emacs (bioperl.lisp comes with the dist.), this may be
> less easy - but people are more than welcome to submit macros that accomplish
> the same thing in their favourite editor. If you're using an editor lacking
> macros, chances are you're using a poor editor and should look at emacs
> anyway :)
> What is more drudgery to me is _filling in_ the documentation template. To an
> API user, this is what's most important though. How would you simplify that?
Can't help you here, since the API has to be written at some point, in some
form or another.
Yes, the macro is handy and is in fact a form of code generation, so it has the
some of the same benefits as I described. I've gotten out of the habit of using
the macro. Thanks for mentioning it.
A problem with it is that the code is generated only once, so if you want to
change the macro to add a new feature, you've got to go in by hand and re-run
it for each method.
> > * Reduces chance of bugs within accessor code (e.g., from
> > cut-n-paste)
> > * Guarantees predictability of accessors across all modules
> Both solved by the macro.
> > * Simple tests could be autogenerated
> That'd be cool. But this doesn't need an auto-generation of methods, right?
Right, but it does require some metadata about the fields within an object.
This is the same metadata that can be used for autogeneration.
If you're not autogenerating, there's the risk that the metadata can get out of
sync with the code, so it would increase maintenace overhead.
> > * Documentation template could be autogenerated
> Macro does this.
> > * Reduces amount of routine code within a module so you
> > can focus on the
> > business logic.
> Macro does this. If it's not boilerplate someone's got to code it anyway.
> > Disadvantages of autogeneration of accessors:
> > * Code is less explicit; can't see all methods when
> > reading module source
> > * Can't validate data when setting (but see below)
> > * Runtime bugs within autogenerated code harder to track down
> > * Performace hit (maybe, not sure about this)
> Allegedly method calls are a performance hit in perl. That's what we've been
> trying to reduce to make the parsers faster. Every method call is a
> performance hit because there is apparently no efficient virtual method
> lookup table.
The performance hit I was getting at was the overhead due to calling an
autogenerated method vs. calling a hard-coded method. The extra lookup time is
probably insignificant to the overhead from the method call itself.
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site