SPUG: Modules - more than one object in file?

Brian Ingerson briani at activestate.com
Thu Oct 12 12:31:30 CDT 2000


Steffen Beyer wrote:
> 
> Hello Todd Wells, in a previous mail you wrote:
> 
> > I'm creating a module which uses some other objects internally, so I have
> > multiple package statements in the same .pm file to define these other
> > objects.  Is there a good reason why I shouldn't do this?  I'd prefer to
> > keep it all in one file.  However, I'm having a problem which I think is
> > related.
> >
> > I have my module all in one file that contains 3 package statements, for
> > objects A, B and C.  e.g.:
> >
> > package A;
> > sub new { blah }
> > sub log { fooblah }
> > 1;
> >
> > package B;
> > @ISA = sq ( A );
> > sub new { blahblah }
> > 1;
> >
> > package C;
> > sub new { moblah }
> > 1;
> >
> > However, when I call
> >
> > $pack_b = B->new();
> > $pack_b->log("foobar"),  I get:
> >
> > Can't locate package "A" for @B::ISA at A.pm line 274.
> > Can't locate package "A" for @B::ISA at A.pm line 274.
> > Can't locate object method "log" via package "B" at A.pm line 274.
> > Can't locate package "A" for @B::ISA.
> >
> > At the moment, my package "A" is just A.pm sitting in the same directory as
> > the program which calls it.
> >
> > Is there a way to make this work or am I forced to put objects A, B and C in
> > separate files?
> 
> Since nobody was able to give you a difinitive answer so far, I'll try to give
> my $0.02 as well - for what it's worth... :-)

You should probably consult a few Perl manuals, a dictionary, and a
shrink, before trying to give a "difinitive" 
answer about Perl.

> 
> Apparently you have to prevent perl from searching the "B" and "C" modules
> in the file system, where they cannot be located because they're no separate
> files and since they're already in memory.

This is entirely out of left field. Perl will only look for modules if
you tell it to, through the 'require' or 'use' commands. (or 'do' or any
number of hand-contrived methods that don't need discussion here :) 

BTW, 'B.pm' *is* a core module, and so actually *would* be found if Perl
went looking for it.

> Therefore you might have to inform perl that the modules are already in
> memory. perl keeps track of this information in the reserved hash %INC -
> not to be confused with @INC, the include path!
> 
> Try this (at the bottom of "A.pm", before the final "1;"):
> 
> $INC{'B.pm'} = $INC{'A.pm'};
> $INC{'C.pm'} = $INC{'A.pm'};

Beware of glittering pearls in a pit of hogwash. It is true that Perl
keeps track of it's modules in %INC when they are require'd or use'd.
But that's not the case here. The rest is hogwash.

> 
> That should work if my extrapolation of how Perl works internally is
> correct! :-)

It's not.

There are 2 reasons why a definitive answer was not given:

1) A definitive problem was not presented.
2) Much can be learned by discussing aspects of the problem, rather than
just saying "You don't need to put your packages in separate files."
(Which, BTW, happens to be true)

Brian

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
      Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
  Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
 For daily traffic, use spug-list for LIST ;  for weekly, spug-list-digest
  Seattle Perl Users Group (SPUG) Home Page: http://www.halcyon.com/spug/





More information about the spug-list mailing list