AUTOLOAD in mod_perl (was Re: When perl is not quite fast enough)

[kyle dawkins <ky...@centralparksoftware.com>]

Perrin (et al... cc'ing this back to the list)

Thanks for this information... it is confirming what I originally 
thought, so I don't need to change my code (yet).  But I wanted to post 
it back to the list to everyone else can benefit from it.

I personally tend to avoid AUTOLOAD, only because it is a piece of perl 
"magic" that can be super-confusing to developers coming to perl (and 
mod_perl) from other languages (um, Java) and I think there's a 
voodoo-level involved that's a bit high for my tastes.  In the one 
place I use it, I don't generate anything, just trap calls to methods 
with AUTOLOAD and perform a lookup based on the arguments.  If it 
really is that slow, maybe I'll even rewrite that to use something 
other than AUTOLOAD.

Cheers!

Kyle Dawkins
Central Park Software


On Tuesday, Dec 17, 2002, at 13:13 US/Eastern, Perrin Harkins wrote:

> kyle dawkins wrote:
>> Sorry to mail you directly... can you just give me two cents on your 
>> comment below about AUTOLOAD, mod_perl and memory sharing?   I use 
>> AUTOLOAD in one module to perform accessors and I wonder if there's a 
>> better way to save memory.
>
> AUTOLOAD is kind of slow, so most people put something in there to 
> define their accessors as subs by manipulating the symbol table.  It's 
> easy, and Damian's book has an example.
>
> In mod_perl, you want any methods that you expect to be called to be 
> defined in the parent process so they will be shared.  I do this by 
> building all of the accessors in a BEGIN block in my module which is 
> called when I use it in startup.pl.
>
> - Perrin
>

Re: AUTOLOAD in mod_perl (was Re: When perl is not quite fast enough)

[Perrin Harkins <pe...@elem.com>]

Christopher Grau wrote:
> I may be veering off-topic, but I've started doing similar things in my
> own code (generating accessor methods via AUTOLOAD).  I ended up writing
> `Class::Autoload,' which I intend to upload to CPAN when I'm done with
> documentation and testing.

Mine was very simple and didn't need to handle any odd cases, which was 
why I didn't bother using a CPAN module.  I would probably check 
Class::MethodMaker before doing it this way again.

I had this in a shared class:

Package Util;

sub build_accessors {
     my ($class, $pkg, $attr_names) = @_;
     no strict 'refs';
     foreach my $attr_name (@{$attr_names}) {
         *{$pkg . "::$attr_name"} = sub { return $_[0]->{$attr_name}; };
     }
}


And then I would put something like this in the classes that needed it:

BEGIN {
   my @attr_names;
   @attr_names = qw(
     foo
     bar
     baz
   );
   Util->build_accessors(__PACKAGE__, \@attr_names);
}

- Perrin

RE: AUTOLOAD in mod_perl (was Re: When perl is not quite fastenough)

[Ben Mathews <bm...@wilcoxassoc.com>]

There is a number of modules on CPAN that already do similar things

Ben


> -----Original Message-----
> From: Christopher Grau [mailto:cgrau@singleclick.com]
> Sent: Tuesday, December 17, 2002 12:05 PM
> To: modperl@apache.org
> Subject: Re: AUTOLOAD in mod_perl (was Re: When perl is not quite
> fastenough)
> 
> I may be veering off-topic, but I've started doing similar things in
my
> own code (generating accessor methods via AUTOLOAD).  I ended up
writing
> `Class::Autoload,' which I intend to upload to CPAN when I'm done with
> documentation and testing.
> 
> Basically, it exports an AUTOLOAD function that will work with the
> %FIELDS hash to insert accessor methods into the symbol table as
> needed.  There's also a compile() method that can be used to
precompile
> the methods, which I thought was relevent, given the mod_perl/memory
> discussion.  It also provides for read-only methods, and a typing
system
> like that of `Class::Class.'
> 
> If there's interest, I'll clutter up the list some more with the POD.
> 
> On Tue, 2002-12-17 at 11:13, kyle dawkins wrote:
> > Perrin (et al... cc'ing this back to the list)
> >
> > Thanks for this information... it is confirming what I originally
> > thought, so I don't need to change my code (yet).  But I wanted to
post
> > it back to the list to everyone else can benefit from it.
> >
> > I personally tend to avoid AUTOLOAD, only because it is a piece of
perl
> > "magic" that can be super-confusing to developers coming to perl
(and
> > mod_perl) from other languages (um, Java) and I think there's a
> > voodoo-level involved that's a bit high for my tastes.  In the one
> > place I use it, I don't generate anything, just trap calls to
methods
> > with AUTOLOAD and perform a lookup based on the arguments.  If it
> > really is that slow, maybe I'll even rewrite that to use something
> > other than AUTOLOAD.
> >
> > Cheers!
> >
> > Kyle Dawkins
> > Central Park Software
> >
> >
> > On Tuesday, Dec 17, 2002, at 13:13 US/Eastern, Perrin Harkins wrote:
> >
> > > kyle dawkins wrote:
> > >> Sorry to mail you directly... can you just give me two cents on
your
> > >> comment below about AUTOLOAD, mod_perl and memory sharing?   I
use
> > >> AUTOLOAD in one module to perform accessors and I wonder if
there's a
> > >> better way to save memory.
> > >
> > > AUTOLOAD is kind of slow, so most people put something in there to
> > > define their accessors as subs by manipulating the symbol table.
It's
> > > easy, and Damian's book has an example.
> > >
> > > In mod_perl, you want any methods that you expect to be called to
be
> > > defined in the parent process so they will be shared.  I do this
by
> > > building all of the accessors in a BEGIN block in my module which
is
> > > called when I use it in startup.pl.
> > >
> > > - Perrin
> > >

Re: AUTOLOAD in mod_perl (was Re: When perl is not quite fast enough)

[Christopher Grau <cg...@singleclick.com>]

I may be veering off-topic, but I've started doing similar things in my
own code (generating accessor methods via AUTOLOAD).  I ended up writing
`Class::Autoload,' which I intend to upload to CPAN when I'm done with
documentation and testing.

Basically, it exports an AUTOLOAD function that will work with the
%FIELDS hash to insert accessor methods into the symbol table as
needed.  There's also a compile() method that can be used to precompile
the methods, which I thought was relevent, given the mod_perl/memory
discussion.  It also provides for read-only methods, and a typing system
like that of `Class::Class.'

If there's interest, I'll clutter up the list some more with the POD.

On Tue, 2002-12-17 at 11:13, kyle dawkins wrote:
> Perrin (et al... cc'ing this back to the list)
> 
> Thanks for this information... it is confirming what I originally 
> thought, so I don't need to change my code (yet).  But I wanted to post 
> it back to the list to everyone else can benefit from it.
> 
> I personally tend to avoid AUTOLOAD, only because it is a piece of perl 
> "magic" that can be super-confusing to developers coming to perl (and 
> mod_perl) from other languages (um, Java) and I think there's a 
> voodoo-level involved that's a bit high for my tastes.  In the one 
> place I use it, I don't generate anything, just trap calls to methods 
> with AUTOLOAD and perform a lookup based on the arguments.  If it 
> really is that slow, maybe I'll even rewrite that to use something 
> other than AUTOLOAD.
> 
> Cheers!
> 
> Kyle Dawkins
> Central Park Software
> 
> 
> On Tuesday, Dec 17, 2002, at 13:13 US/Eastern, Perrin Harkins wrote:
> 
> > kyle dawkins wrote:
> >> Sorry to mail you directly... can you just give me two cents on your 
> >> comment below about AUTOLOAD, mod_perl and memory sharing?   I use 
> >> AUTOLOAD in one module to perform accessors and I wonder if there's a 
> >> better way to save memory.
> >
> > AUTOLOAD is kind of slow, so most people put something in there to 
> > define their accessors as subs by manipulating the symbol table.  It's 
> > easy, and Damian's book has an example.
> >
> > In mod_perl, you want any methods that you expect to be called to be 
> > defined in the parent process so they will be shared.  I do this by 
> > building all of the accessors in a BEGIN block in my module which is 
> > called when I use it in startup.pl.
> >
> > - Perrin
> >