in reply to Cross-Package/Object Communication

My intuition tells me that you've invented "data thingies" that don't actually map into real world objects, and thus their roles are muddy (at least in your description).

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

  • Comment on •Re: Cross-Package/Object Communication

Replies are listed 'Best First'.
Re: Re: Cross-Package/Object Communication
by billyak (Friar) on Aug 21, 2002 at 16:15 UTC
    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
[reply]
[d/l]
Re: •Re: Cross-Package/Object Communication
by IOrdy (Friar) on Aug 21, 2002 at 16:28 UTC
    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'.
[reply]

In Section Seekers of Perl Wisdom