Besides that, string eval still has a few memory leaks, even in the latest versions of Perl. (That might change in the next week or two, but it doesn't help you right now.)

Here's another thought. If you're generating these with an AUTOLOAD mechanism, you could potentially poison your method dispatch cache. That'll slow down the next method call. (Or I could be crazy... that sounds right, but I can't find it documented right now... sorry.)

Update: It's in gv.c, specifically Perl_gv_fetchmeth. I've read scarier things, but don't ask for an annotation. ow! It's not available from user space, so there's no documentation. Modifying @ISA will mess with it, though.

Umm if you do find the documentation id be interested to know a bit more about this poisened method cache.

Cheers,

Yves
--
You are not ready to use symrefs unless you already know why they are bad. -- tadmc (CLPM)

                - Ant
                - Some of my best work - Fish Dinner

sub getset_subs {
  return [qw/size height weight/];
}
[download]

That can be used by the generator program to take the existing package and add a bunch of set/get subs to the end of it.

This isn't perfect for all situations, you don't always know what you want before hand. But memory is cheap, IMO always calculate & produce code before hand if you can instead of producing the same structures at runtime again and again. Just make sure to keep the machine generated code machine generated. Editing machine generated code is a maintenance nightmare.

-jackdied

Believe it or not, I'm trying to propose an alternate solution to machine generated code. The problem is that the maintainance headaches move from the code to the generator. Since the generator is almost always a reinvention of the wheel, it's much more difficult to maintain. Having that layer of abstraction, I've found, isn't usually worth it.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

I worked for a pure-perl company for a couple years, and we used quite a bit of generated code to good effect. You are right in that you have to pick your battles or you can get screwed.

Things that generate very well are expressable in XML. If you can't express it easilly in static XML, it isn't a good place to generate. Good examples are database schemas - you then generate the perl accessors and also create/alter scripts from one source. Another is lists of static text to pre/append to pages depending on user preferences - like what level of help they require.

<help page="user-settings">
  <tip level="novice">
    Do not touch anything, the defaults are fine
  </tip>
  <tip level="admin">
    Changing the starting day of the week will impact reports and time
+ sheets
  </tip>
</help>
[download]

The usage in perl would be like $page->print_hints(-hint_level=>$user->setting('hintlevel')); The perl is overly verbose, but you get the idea.

-jackdied