Watching the CB I feel that what you are after is a Singleton. You can derive from Class::Singleton or just as easily roll your own.

package Mold;
our $Singleton;

sub new {
  return $Singleton if defined $Singleton;
  my $class=shift;
  $Singleton=bless{},$class;
  $Singleton->init(@_);
  return $Singleton;
}  

...

1;
[download]

Now all you have to do to get the same Mold object every time anywhere is to say Mold->new().

This is not an uncommon pattern, and is conceptually identical to a global var, except that it gives you an interface isolation layer that makes your code much easier to maintain.

sub spawn
{
   my $this=shift or die;
   my $class=ref($this) || $this;
   my $self = { };
   bless $self,$class;
   $self->{parent}=$self || die;
   $self->{mold}=$self || die;
   $self->init;
   return($self);
}
[download]

sub init
{
   my $self=shift;

   $SIG{__DIE__} = sub {endwin; };
   $SIG{__WARN__} = sub {
      endwin;
      warn @_;
      my $i = 0;
      while (my($pkg, $file, $line) = caller($i++)) {
         warn "  package $pkg, file $file, line $line\n";
      }
   };

   $self->{prefs} = Prefs->spawn($self);
   $self->{prefs}->load_rc();
   $self->{prefs}->load_terrains($self->{prefs}->{datadir} . "/terrain
+s");


   $self->{uic} = UI_Curses->spawn($self);
   $self->{com_int} = Command_Interpreter->spawn($self);
   $self->{grid} = Grid->spawn($self);
   $self->{com_proc} = Command_Processor->spawn($self);
   $self->{player} = Player->spawn($self);
   $self->{eq} = EventQueue->spawn($self);
   $self->{data_monsters} = Data::Monsters->spawn($self);
   $self->{msg} = Message->spawn($self);

   $self->{eq}->addclass('thingy');

}
[download]

every one of those spawn commands use Standard.pm to inherit the spawn command.

And my goal is to stop passing along $self.

Look at the order of events here. BEFORE $main::mold gets assigned a value the following calls are made:

Mold::spawn
Mold::init
Prefs::spawn
UI_Curses::spawn
Command_Interpreter::spawn
Grid::spawn
Command_Processor::spawn
Player::spawn
EventQueue::spawn
Data::Monsters::spawn
Message::spawn
[download]

So if any of those subs expect $main::mold to already have a value they would be wrong.

Im guessing that you should either alter Mold::spawn so that it says

sub spawn
{
   my $this=shift or die;
   my $class=ref($this) || $this;
   my $self = bless {},$class;
   $main::mold=$self;
   $self->init()
   return($self);
}
[download]

Or remove the call to init() from the constructor and change the code in main to be

$mold=Mold->spawn;
$mold->init();
[download]

Also the self references that you put in there

   $self->{parent}=$self || die;
   $self->{mold}=$self || die;
[download]

will cause a memory leak unless they are eventually changed.

A better design pattern for things like that is to use a pattern where the self referential structure is not itself the root object. Then the DESTORY method in the root object can safely remove the self references and the whole object will destruct when it falls out of scope.


---
demerphq

_{<Elian> And I do take a kind of perverse pleasure in having an OO assembly language...}

$mold=Mold->spawn;
[download]

I thought that Standard::spawn() was really Mold::spawn() here. My apologies. Theres not much we can do to help without knowing what Mold::spawn() looks like. Suffice it to say that this is a good example of checking to see if constructors actually suceed.

$mold=Mold->spawn() or die "Mold wont spawn!";
[download]

Would tell you if Mold::spawn() actually returned anything.

You've all lost me.

Since Mold.pm doesn't define Mold->spawn, but instead defines Standard->spawn, why was this ever expected to work?