If you make the 'Primary' object a singleton then you can whip it up whenver you like:

 my $primary = Primary->instance;
 my $name = $primary->name;
 # or if you only need one item from it
 my $name = Primary->instance->name;
[download]

See code implementing a singleton at Re: how to make a universally inherited method?

Chris
M-x auto-bs-mode

Thanks! You just saved me so much work it is disturbing. A problem seemingly so large that is easily corrected with a few lines of code. Simply amazing. Thank you.

-billyak

I'd suggest you go back to role-playing the real task, and seeing who needs to talk to what. In general, a "manager object" is a very bad idea, especially when it turns out to be a singleton. You've just thrown away most of the advantages of OO when you get to that point.

For example, the LWP::UserAgent class might at first glance appear to be a "manager object", but it's really an object that maps to a particular browser, which is a real thing. And just as you can have multiple browsers, on your desktop, you can have multiple instances of LWP::UserAgent in your program.

So, rethink your problem from the perspective of actors, not data, and your need for a "Primary object" will probably go away or take on an obvious new role. Such is the OO way.

-- Randal L. Schwartz, Perl hacker

My problem is how to "start" an OO program. From what I've done, it has always been something like



use x;
my $x = new x;
$x->set(blah=>"four");
$x->go;
[download]

Or something to that extent. Perhaps it is my fear of going non-OO in the launcher/manager part that is holding me back. Is it standard to have XML parsing or other config stuff non-OO fed into the objects to start the actual process? I could have a %main::CONFIG and pass that to all the objects that are initialized? That still doesn't change the fact that the ref to the config stuff has to be passed on to every object I initialize, though.

So it is safe so say that I am still confused as to how to work this.

-billyak

I don’t quite understand what you are saying, you don’t happen to know of any real world examples as the whole "perspective of actors" isn't sinking into my poor brain.

I went and looked for examples of controlling large projects and scoop used a singleton and only one class from memory. Also it seemed to be the norm amongst most projects to have a 'manager object'.

Since you were talking about config parameters and such....

I usually have a package that defines some constants, and use it like

  use My::Constants qw/ MY_FOO MY_BAR MY_LOGFILE_NAME /;

  my $fh = IO::File->new( MY_LOGFILE_NAME );
  ....
[download]

My::Constants has default values for those constants, and optionally overrides those values with values that it reads from a XML config file , or from %ENV

I do this instead of using a config hash or something mainly because I wanted a compile time check of config variable names

Great idea! After maybe half an hour (hey, I did figure it out) I can make an empty hash or array ref as a constant then bless _that_. So my object ref will be a constant. :) Excellent.

-billyak