You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Philip Molter <ph...@datafoundry.net> on 2000/08/26 00:33:41 UTC
Module Function Name Issue
I have a module with some code like this:
package Object;
sub new {
my $class = shift;
return bless {}, $class;
}
sub SubObj {
Object::SubObj->new();
}
1;
package Object::SubObj;
sub new {
my $class = shift;
return bless {}, $class;
}
I have a script with code like this:
$obj = Object->new();
$sub = Object->SubObj();
Now, I can spot the potential problem. Under regular perl, this
methodology works fine, has been for several years (that's how
long we've had this module). Under mod_perl, this setup works
fine. It has for several years. However, on a recent new system,
I decided that this module needed to be preloaded in a startup.pl-type
script, like so:
use Object;
Nothing fancy. When the script above is called in mod_perl now,
it goes into an endless loop. Apparently, the $obj->SubObj(); call
results in it calling itself continuously, as Object::SubObj is
mapped to the function, not the class. To fix it, I did:
sub SubObj {
'Object::SubObj'->new();
}
Why does this work under regular perl and under mod_perl, but under
mod_perl with this module preloaded, perl has a problem deciding
whether this is a function or a class? Is this a bug in mod_perl's
methodology or is it just another case of mod_perl catching bad
programming practice (no comments about the programming practice;
I only fix it)?
Is this in the Perl Guide? If so, I missed it. If not, would it
be appropriate to add it as an example? This was a challenge to
track down, especially with the way it affected the system (one
gets very scared running code he knows is going into an endless
loop in a location he can't determine).
* Philip Molter
* Data Foundry International
* http://www.datafoundry.net/
* philip@datafoundry.net
Re: Module Function Name Issue
Posted by Stas Bekman <st...@stason.org>.
On Sat, 26 Aug 2000, Philip Molter wrote:
> On Sat, Aug 26, 2000 at 05:22:27PM +0200, Stas Bekman wrote:
>
> : The following is a known kludge, but it doesn't seem to apply in your
> : case (I thought you might use it in PerlHandler)
> :
> : =head1 More package name related issues
> :
> : If you have the following:
> :
> : PerlHandler Apache::Work::Foo
> : PerlHandler Apache::Work::Foo::Bar
> :
> : And you make a request that pulls in C<Apache/Work/Foo/Bar.pm> first,
> : then the C<Apache::Work::Foo> package gets defined, so mod_perl does
> : not try to pull in C<Apache/Work/Foo.pm>
>
> Yes, I read that. I don't know if the issue is one in the same.
> Because they are in the same file, Object.pm is definitely being
> loaded first. However, what happens differently when a module is
> loaded at initial startup versus when the same module is loaded
> when a script runs?
Do you see the same behaviour if you split the two packages into two
different files?
> : > : > I have a module with some code like this:
> : > : >
> : > : > package Object;
> : > :
> : > : => use Object::SubObj;
> : > :
> : > : > sub new {
> : > : > my $class = shift;
> : > : > return bless {}, $class;
> : > : > }
> : > : >
> : > : > sub SubObj {
> : > : > Object::SubObj->new();
> : > : > }
> : > : >
> : > : > package Object::SubObj;
> : > : > sub new {
> : > : > my $class = shift;
> : > : > return bless {}, $class;
> : > : > }
> : > : >
> : > : > I have a script with code like this:
> : > : >
> : > : > $obj = Object->new();
> : > : > $sub = Object->SubObj();
> :
> : How about:
> :
> : $sub = Object::SubObj();
> :
> : Your sub 'SubObj' isn't a method, so you should call it as a function and
> : not a method.
>
> Well, except, in the effort to simplify all this, the $obj->SubObj()
> method doesn't just pass in nothing. It passes in various bits of
> information contained in the Object-class object. The sub SubObj
> is more like:
>
> sub SubObj {
> my ( $this ) = @_;
> Object::SubObj->new( $this->{'var1'}, $this->{'var2'} );
> }
>
> So it's actually tied pretty much to the POO interface. I mean,
> it's basically not /that/ big a deal, because by writing it:
>
> sub SubObj {
> my ( $this ) = @_;
> 'Object::SubObj'->new( $this->{'var1'}, $this->{'var2'} );
> }
>
> the whole problem is averted. I'm really just wondering what
> happens differently when the module is loaded from a startup.pl
> script via PerlRequire (the PerlHandler is Apache::Registry) versus
> when it's loaded as a result of a script call, because those
> differences may cause other problems in the future.
I'd try to run it under debugger and see where the problem occurs. If you
can send a *short* and *simple* example that one can reproduce the problem
with someone will test it.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com perl.org apache.org
Re: Module Function Name Issue
Posted by Philip Molter <ph...@datafoundry.net>.
On Sat, Aug 26, 2000 at 05:22:27PM +0200, Stas Bekman wrote:
: The following is a known kludge, but it doesn't seem to apply in your
: case (I thought you might use it in PerlHandler)
:
: =head1 More package name related issues
:
: If you have the following:
:
: PerlHandler Apache::Work::Foo
: PerlHandler Apache::Work::Foo::Bar
:
: And you make a request that pulls in C<Apache/Work/Foo/Bar.pm> first,
: then the C<Apache::Work::Foo> package gets defined, so mod_perl does
: not try to pull in C<Apache/Work/Foo.pm>
Yes, I read that. I don't know if the issue is one in the same.
Because they are in the same file, Object.pm is definitely being
loaded first. However, what happens differently when a module is
loaded at initial startup versus when the same module is loaded
when a script runs?
: > : > I have a module with some code like this:
: > : >
: > : > package Object;
: > :
: > : => use Object::SubObj;
: > :
: > : > sub new {
: > : > my $class = shift;
: > : > return bless {}, $class;
: > : > }
: > : >
: > : > sub SubObj {
: > : > Object::SubObj->new();
: > : > }
: > : >
: > : > package Object::SubObj;
: > : > sub new {
: > : > my $class = shift;
: > : > return bless {}, $class;
: > : > }
: > : >
: > : > I have a script with code like this:
: > : >
: > : > $obj = Object->new();
: > : > $sub = Object->SubObj();
:
: How about:
:
: $sub = Object::SubObj();
:
: Your sub 'SubObj' isn't a method, so you should call it as a function and
: not a method.
Well, except, in the effort to simplify all this, the $obj->SubObj()
method doesn't just pass in nothing. It passes in various bits of
information contained in the Object-class object. The sub SubObj
is more like:
sub SubObj {
my ( $this ) = @_;
Object::SubObj->new( $this->{'var1'}, $this->{'var2'} );
}
So it's actually tied pretty much to the POO interface. I mean,
it's basically not /that/ big a deal, because by writing it:
sub SubObj {
my ( $this ) = @_;
'Object::SubObj'->new( $this->{'var1'}, $this->{'var2'} );
}
the whole problem is averted. I'm really just wondering what
happens differently when the module is loaded from a startup.pl
script via PerlRequire (the PerlHandler is Apache::Registry) versus
when it's loaded as a result of a script call, because those
differences may cause other problems in the future.
* Philip Molter
* Data Foundry International
* http://www.datafoundry.net/
* philip@datafoundry.net
Re: Module Function Name Issue
Posted by Stas Bekman <st...@stason.org>.
On Sat, 26 Aug 2000, Philip Molter wrote:
> On Sat, Aug 26, 2000 at 01:56:18PM +0200, Stas Bekman wrote:
> : On Fri, 25 Aug 2000, Philip Molter wrote:
> :
> : Do you have the two packages in the same file like you have presented
> : below? I guess they aren't since you have '1;' just before the declaration
> : of the second package. If they live in two different files obviously that
> : 'use Object::SubObj' is mising, see the code below. Object doesn't know
> : about Object::SubObj if you don't tell it about it.
> :
> : So how exactly your files are organized?
>
> Actually, that '1;' was a mistake. Yes, they are both in the same
> file, and no, that '1;' is not really there.
The following is a known kludge, but it doesn't seem to apply in your
case (I thought you might use it in PerlHandler)
=head1 More package name related issues
If you have the following:
PerlHandler Apache::Work::Foo
PerlHandler Apache::Work::Foo::Bar
And you make a request that pulls in C<Apache/Work/Foo/Bar.pm> first,
then the C<Apache::Work::Foo> package gets defined, so mod_perl does
not try to pull in C<Apache/Work/Foo.pm>
> : > I have a module with some code like this:
> : >
> : > package Object;
> :
> : => use Object::SubObj;
> :
> : > sub new {
> : > my $class = shift;
> : > return bless {}, $class;
> : > }
> : >
> : > sub SubObj {
> : > Object::SubObj->new();
> : > }
> : >
> : > package Object::SubObj;
> : > sub new {
> : > my $class = shift;
> : > return bless {}, $class;
> : > }
> : >
> : > I have a script with code like this:
> : >
> : > $obj = Object->new();
> : > $sub = Object->SubObj();
How about:
$sub = Object::SubObj();
Your sub 'SubObj' isn't a method, so you should call it as a function and
not a method.
> : > Now, I can spot the potential problem. Under regular perl, this
> : > methodology works fine, has been for several years (that's how
> : > long we've had this module). Under mod_perl, this setup works
> : > fine. It has for several years. However, on a recent new system,
> : > I decided that this module needed to be preloaded in a startup.pl-type
> : > script, like so:
> : >
> : > use Object;
> : >
> : > Nothing fancy. When the script above is called in mod_perl now,
> : > it goes into an endless loop. Apparently, the $obj->SubObj(); call
> : > results in it calling itself continuously, as Object::SubObj is
> : > mapped to the function, not the class. To fix it, I did:
> : >
> : > sub SubObj {
> : > 'Object::SubObj'->new();
> : > }
> : >
> : > Why does this work under regular perl and under mod_perl, but under
> : > mod_perl with this module preloaded, perl has a problem deciding
> : > whether this is a function or a class? Is this a bug in mod_perl's
> : > methodology or is it just another case of mod_perl catching bad
> : > programming practice (no comments about the programming practice;
> : > I only fix it)?
> : >
> : > Is this in the Perl Guide? If so, I missed it. If not, would it
> : > be appropriate to add it as an example? This was a challenge to
> : > track down, especially with the way it affected the system (one
> : > gets very scared running code he knows is going into an endless
> : > loop in a location he can't determine).
> : >
> : > * Philip Molter
> : > * Data Foundry International
> : > * http://www.datafoundry.net/
> : > * philip@datafoundry.net
> : >
> :
> :
> :
> : _____________________________________________________________________
> : Stas Bekman JAm_pH -- Just Another mod_perl Hacker
> : http://stason.org/ mod_perl Guide http://perl.apache.org/guide
> : mailto:stas@stason.org http://apachetoday.com http://jazzvalley.com
> : http://singlesheaven.com http://perlmonth.com perl.org apache.org
> :
>
> * Philip Molter
> * Data Foundry International
> * http://www.datafoundry.net/
> * philip@datafoundry.net
>
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com perl.org apache.org
Re: Module Function Name Issue
Posted by Philip Molter <ph...@datafoundry.net>.
On Sat, Aug 26, 2000 at 01:56:18PM +0200, Stas Bekman wrote:
: On Fri, 25 Aug 2000, Philip Molter wrote:
:
: Do you have the two packages in the same file like you have presented
: below? I guess they aren't since you have '1;' just before the declaration
: of the second package. If they live in two different files obviously that
: 'use Object::SubObj' is mising, see the code below. Object doesn't know
: about Object::SubObj if you don't tell it about it.
:
: So how exactly your files are organized?
Actually, that '1;' was a mistake. Yes, they are both in the same
file, and no, that '1;' is not really there.
: > I have a module with some code like this:
: >
: > package Object;
:
: => use Object::SubObj;
:
: > sub new {
: > my $class = shift;
: > return bless {}, $class;
: > }
: >
: > sub SubObj {
: > Object::SubObj->new();
: > }
: >
: > package Object::SubObj;
: > sub new {
: > my $class = shift;
: > return bless {}, $class;
: > }
: >
: > I have a script with code like this:
: >
: > $obj = Object->new();
: > $sub = Object->SubObj();
: >
: > Now, I can spot the potential problem. Under regular perl, this
: > methodology works fine, has been for several years (that's how
: > long we've had this module). Under mod_perl, this setup works
: > fine. It has for several years. However, on a recent new system,
: > I decided that this module needed to be preloaded in a startup.pl-type
: > script, like so:
: >
: > use Object;
: >
: > Nothing fancy. When the script above is called in mod_perl now,
: > it goes into an endless loop. Apparently, the $obj->SubObj(); call
: > results in it calling itself continuously, as Object::SubObj is
: > mapped to the function, not the class. To fix it, I did:
: >
: > sub SubObj {
: > 'Object::SubObj'->new();
: > }
: >
: > Why does this work under regular perl and under mod_perl, but under
: > mod_perl with this module preloaded, perl has a problem deciding
: > whether this is a function or a class? Is this a bug in mod_perl's
: > methodology or is it just another case of mod_perl catching bad
: > programming practice (no comments about the programming practice;
: > I only fix it)?
: >
: > Is this in the Perl Guide? If so, I missed it. If not, would it
: > be appropriate to add it as an example? This was a challenge to
: > track down, especially with the way it affected the system (one
: > gets very scared running code he knows is going into an endless
: > loop in a location he can't determine).
: >
: > * Philip Molter
: > * Data Foundry International
: > * http://www.datafoundry.net/
: > * philip@datafoundry.net
: >
:
:
:
: _____________________________________________________________________
: Stas Bekman JAm_pH -- Just Another mod_perl Hacker
: http://stason.org/ mod_perl Guide http://perl.apache.org/guide
: mailto:stas@stason.org http://apachetoday.com http://jazzvalley.com
: http://singlesheaven.com http://perlmonth.com perl.org apache.org
:
* Philip Molter
* Data Foundry International
* http://www.datafoundry.net/
* philip@datafoundry.net
Re: Module Function Name Issue
Posted by Ken Williams <ke...@forum.swarthmore.edu>.
philip@datafoundry.net (Philip Molter) wrote:
>I have a module with some code like this:
>
> package Object;
> sub new {
> my $class = shift;
> return bless {}, $class;
> }
>
> sub SubObj {
> Object::SubObj->new();
> }
>
> 1;
>
> package Object::SubObj;
> sub new {
> my $class = shift;
> return bless {}, $class;
> }
This problm isn't atually directly related to mod_perl, it only happens there
because the Perl uses various heuristics to decide whether the ambiguous
notation Blah::Arf->subr means Blah::Arf()->subr() or 'Blah::Arf'->subr(). In
the first case it calls the Arf package in the Blah package, which returns a
blessed object, and then it calls that rturned object's subr() method. In the
second case, it calls the subr() method of the Blah::Arf class.
I prefer to treat this ambiguous notation as a black box - Perl may choose one
way or the other, but I don't care to figure out what its rules are. The rules
might be complicated or stupid, or they might be intuitive and smart, but I
prefer to steer clear of the whole situation. In your case, something about
the loading order & code persistence under mod_perl is reversing the sense of
the ambiguity. You can either try to figure out why that's happening, or avoid
the issue altogether.
To disambiguate, you can use the workaround you've already found, or use
the compile-time mechanism given by newer Perls (5.005+):
Object::SubObj::->new();
------------------- -------------------
Ken Williams Last Bastion of Euclidity
ken@forum.swarthmore.edu The Math Forum
Re: Module Function Name Issue
Posted by Stas Bekman <st...@stason.org>.
On Fri, 25 Aug 2000, Philip Molter wrote:
Do you have the two packages in the same file like you have presented
below? I guess they aren't since you have '1;' just before the declaration
of the second package. If they live in two different files obviously that
'use Object::SubObj' is mising, see the code below. Object doesn't know
about Object::SubObj if you don't tell it about it.
So how exactly your files are organized?
> I have a module with some code like this:
>
> package Object;
=> use Object::SubObj;
> sub new {
> my $class = shift;
> return bless {}, $class;
> }
>
> sub SubObj {
> Object::SubObj->new();
> }
>
> 1;
>
> package Object::SubObj;
> sub new {
> my $class = shift;
> return bless {}, $class;
> }
>
> I have a script with code like this:
>
> $obj = Object->new();
> $sub = Object->SubObj();
>
> Now, I can spot the potential problem. Under regular perl, this
> methodology works fine, has been for several years (that's how
> long we've had this module). Under mod_perl, this setup works
> fine. It has for several years. However, on a recent new system,
> I decided that this module needed to be preloaded in a startup.pl-type
> script, like so:
>
> use Object;
>
> Nothing fancy. When the script above is called in mod_perl now,
> it goes into an endless loop. Apparently, the $obj->SubObj(); call
> results in it calling itself continuously, as Object::SubObj is
> mapped to the function, not the class. To fix it, I did:
>
> sub SubObj {
> 'Object::SubObj'->new();
> }
>
> Why does this work under regular perl and under mod_perl, but under
> mod_perl with this module preloaded, perl has a problem deciding
> whether this is a function or a class? Is this a bug in mod_perl's
> methodology or is it just another case of mod_perl catching bad
> programming practice (no comments about the programming practice;
> I only fix it)?
>
> Is this in the Perl Guide? If so, I missed it. If not, would it
> be appropriate to add it as an example? This was a challenge to
> track down, especially with the way it affected the system (one
> gets very scared running code he knows is going into an endless
> loop in a location he can't determine).
>
> * Philip Molter
> * Data Foundry International
> * http://www.datafoundry.net/
> * philip@datafoundry.net
>
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com perl.org apache.org