in reply to Re: Re: Optimizing away calls to functions defined in eval
in thread Optimizing away calls to functions defined in eval

What you really want is to generate the subs before hand, from some resourcefile (XML works well). You can even have the seutp be part of the package

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

Replies are listed 'Best First'.
Re: Re: Re: Re: Optimizing away calls to functions defined in eval
by dragonchild (Archbishop) on Oct 17, 2001 at 02:23 UTC
    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.

[reply]
      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

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom