in reply to Avoiding global object handle

As the modules, written as OO modules, are written for reuse between applications there is no logical reason to instantiate more than one object of the class within the application using the module. At the moment of instantiation an object handle is retrieved and stored.
Then you don't really have instances any more. You have a singleton. And a package is a fine singleton.

Don't make the same mistake as our favorite whipping boy, CGI.pm. If you're always going to have at most one of a thing in an application, use class methods, not instances methods, and lexical variables for member variables. Fast. Easy. And subclassable, if done right.

-- Randal L. Schwartz, Perl hacker

Replies are listed 'Best First'.
Re: •Re: Avoiding global object handle
by gregorovius (Friar) on Mar 27, 2002 at 17:11 UTC
    I see your point about classwide methods on a package being a singleton, the class itself being like a single instance with lexical member variables.

    In practice, though, I have found that classwide methods make it hard to replace functionality by subclassing, because one needs to hardcode the package name everywhere its methods are called. Then, when subclassing the singleton package, one needs to replace all those calls to instead use the name of the subclass. Do you know if there's a way around this?

    I think this is a shortcoming of using classwide methods. Where I work we now instead favor having Factory classes for producing singleton variables that we make available as "framework globals" as described in my earlier posting. This Factory class reads a configuration file in order to determine what kind of subclass it should instantiate, which works great for plug-and-play configuration of different installs of our application. Example: 

     

$FOO = FooFactory->get_foo();

    [download]
    As a convention we use all-caps for singleton variables.
[reply]
[d/l]
[reply]
[d/l]

In Section Seekers of Perl Wisdom