Re: Module Function Name Issue

2000-08-27 Thread Ken Williams

[EMAIL PROTECTED] (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
  [EMAIL PROTECTED]The Math Forum





Re: Module Function Name Issue

2000-08-26 Thread Stas Bekman

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/
 * [EMAIL PROTECTED]
 



_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com   perl.org   apache.org





Re: Module Function Name Issue

2000-08-26 Thread Philip Molter

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/
:  * [EMAIL PROTECTED]
:  
: 
: 
: 
: _
: Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
: http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
: mailto:[EMAIL PROTECTED]   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/
* [EMAIL PROTECTED]



Re: Module Function Name Issue

2000-08-26 Thread Stas Bekman

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 CApache/Work/Foo/Bar.pm first,
then the CApache::Work::Foo package gets defined, so mod_perl does
not try to pull in CApache/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/
 :  * [EMAIL PROTECTED]
 :  
 : 
 : 
 : 
 : _
 : Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
 : http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
 : mailto:[EMAIL PROTECTED]   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/
 * [EMAIL PROTECTED]
 



_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com   perl.org   apache.org





Re: Module Function Name Issue

2000-08-26 Thread Stas Bekman

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 CApache/Work/Foo/Bar.pm first,
 : then the CApache::Work::Foo package gets defined, so mod_perl does
 : not try to pull in CApache/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:[EMAIL PROTECTED]   http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com   perl.org   apache.org