You could also take a look at Class::Singleton. Possibly you could subclass this to be a repository for handles. For instance, (assuming $rep is an instance of a subclass of Class::Singleton) add a handle using $rep->add_handle("Module1", Module1->new() );, then call $rep->get_handle("Module1") to retrieve the handle later. Of course, you'll need to write these methods yourself.

That way, you only need to add use Rep; our $rep = Rep->new(); into the modules that will need to access any of the handles.

It has the same effect of having globals, but just seems to me a bit cleaner, along with less names of globals running around.

You dismissed method 2 as possibly being too much of a performance hit, since it involves passing a scalar variable containing a reference into each subroutine.

But your preferred method involves calling an extra subroutine every time you want to access your object. I haven't done any tests, but I'd be surprised if sticking an extra param in an existing sub call is more costly than making a whole new call. Especially if in a particular sub you do ten method calls on your object — you've now replaced one param with ten function calls.

Did you actually have a problem with your code running too slow, or did you just get the urge to do this because you suspected there might be one?

If I have to call the get_handle() when I need it, I can appreciate that there's a performance cost. But pulling this handle through numerous calls to subs that don't need the handle themself, with the only reason to provide the handle to a 'sub-sub' feels as paying for something without getting anything in return.

Furthermore, imagine three subs named x(), y() and z(). sub x() calls sub y() that calls sub z().

One day sub z() is changed and needs access to the handle. As a result, the programmer must change sub x() and sub y() to take the handle as a parameter even though they couldn't care less about the handle themself.

This would lead to discussions like: "If we want to change sub z() to use the functionality of Module.pm, then we must first do an impact analyze to determine how many other subs must be enhanced to provide the handle, directly or indirectly, to our sub z()".

If sub z() can get a direct access to the handle, the change can be implemented in sub z() with no impact on other subs.

Yes, I'm talking about rather big and complex Perl applications here.



---

Everything went worng, just as foreseen.

"Especially if in a particular sub you do ten method calls on your object — you've now replaced one param with ten function calls."

Not necessarily. If I know that I'm going to use the object 10 times in a specific sub, I can call get_handle() once and save the handle in my own variable throughout the sub.

sub z {
my $handle=get_handle();
$handle->method_a('parameter');
$handle->method_b('parameter');
$handle->method_c('parameter');
# Etc.
}
[download]





---

Everything went worng, just as foreseen.

    sub make_handle {
        ...
    }

    our $handle = make_handle(); # "... used only once"
[download]

sub foo {
    my $foo = shift;
    return undef unless defined $foo;
    no warnings 'redefine';
    *foo = sub { $foo };
    foo();
}

{
    my $bar;
    sub bar {
        defined $bar ? $bar : ($bar = shift);
    }
}
[download]

I don't quite see the point in having a global function instead of a global variable. To me it makes more sense to have a global variable since that needs to be declared.

Accessing the global handle through a subroutine makes it much harder to accidentally clobber it. (Further, it makes clear to anyone reading your code that $handle has a well-defined value that doesn't change, which is kind of nice for maintenance programmers.)

In general, I'm a big fan of wrapping related scope-specific variables in a singleton class, just because it makes domain control so much easier. This works best in very specific cases, where you don't see much potential for partial code reuse, because you're coupling all the code that depends on the singleton. It becomes correspondingly harder to pull out individual functions from that scope and use them elsewhere, because you have to pull out the singleton as well (which probably doesn't fit your new problem perfectly). In Biker's situation, this might be a good fit.

--
:wq

I'm speaking, of course, of when it's best fit to use a variable/subroutine instead of some other technique.

Accessing the global handle through a subroutine makes it much harder to accidentally clobber it.

True. I didn't think of that, especially since he uses it as foo()->bar, and it's hard to modify it that way. I don't think there's a high risk of accidently modifying this particular variable, but I see your objection.

(Further, it makes clear to anyone reading your code that $handle has a well-defined value that doesn't change, which is kind of nice for maintenance programmers.)

By convention you name those variables in upper-case, so in this case it would be $HANDLE instead. There should be no larger question marks regarding that issue.

I think that the small risk of clobbering the variable is out-matched by the warning feature of variables. It helps to keep code clean, and that is something maintainers also appreciate. I hate seeing unused subs/variables just because the author was too afraid/paranoid to remove them.

Cheers,
-Anomo

I don't quite see the point in having a global function instead of a global variable

One thing it does buy you is the ability to drop a breakpoint on it in the debugger, and then play with caller to see where you were called from. That is not quite as simple to do with a variable.

In a farfetched scenario, you could also diddle the package's symbol table to wrap or replace the function itself. That's much harder to do with a variable.


print@_{sort keys %_},$/if%_=split//,'= & *a?b:e\f/h^h!j+n,o@o;r$s-t%t#u'

As per suggestion above, I have read up on Singleton. This proved to be very interesting reading indeed.

"The instance() method is used to create a new Class::Singleton instance, or return a reference to an existing instance. Using this method, it is only possible to have a single instance of the class in any system."

But it is not the solution to my situation. I want the object to exist in one instance per application within the system. Not one instance per system.

Some bad wording in the documentation. It's actually one instance per process.

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.

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

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.

So just use a string as the classname!

my $object = 'ThisClass';
...
$object->this;
$object->that;
[download]

-- Randal L. Schwartz, Perl hacker

package MyFramework;
use strict;

use Exporter;
use vars qw(@ISA @EXPORT @EXPORT_OK);

@ISA = qw(Exporter);

@EXPORT_OK = qw( $HANDLE );

1;
[download]

use MyFramework qw ( $HANDLE );
[download]

This approach is equivalent to your "get_handle" method because it ensures that the same instance will be used by all. It also makes it easy to replace the class that produces the handle, because it would only be invoked once in the whole of your code, at the place where $HANDLE is initialized.

Whenever I catch myself passing a bunch of the same arguments to myriad subs, I stuff em into a hash and just pass it around.

--
$you = new YOU;
honk() if $you->love(perl)