mp has asked for the wisdom of the Perl Monks concerning the following question:

For class data, I've been using this sort of structure, which creates a closure. $class_data could be anything. One example is a Cache::FileCache. 
package Some::Package::Name;
use strict;
use warnings;

my $class_data;

sub some_class_method {
  my $class = shift;
  some_operation_to_define($class_data);
}

sub some_other_class_method {
  my $class = shift;
  return some_fuction_based_on($class_data);
}

[download]
Are there any pitfalls with this approach (e.g. memory leaks)? Is there any reason (other than to allow it to be set from outside the package) to change 
my $class_data;

[download]
to 
our $class_data;

[download]
?

Replies are listed 'Best First'.
Re: "our" versus "my" for class data
by revdiablo (Prior) on Aug 07, 2004 at 23:10 UTC

    I'm not sure whether you meant to imply this or not, but one big difference between using my and our, is that our does not really create a closure.* You hint at this when you say our "allow[s] it to be set from outside the package," but I just thought it could use some explicit clarification.

    * Update: actually, the snippet using our does create a closure, but the thing being closed on is not the variable itself. See this post by tilly for details.

    Compare:

    {
    our $foo;
    sub inc { ++$foo }
}

print inc for 1 .. 5;
our $foo;
print ++$foo;

    [download]

    To:

    {
    my $foo;
    sub inc { ++$foo }
}

print inc for 1 .. 5;
my $foo;
print ++$foo;

    [download]

    The neat thing about closures is that they allow the variable to persist, while also protecting it from the outside. Using our does not.

[reply]
[d/l]
[select]
      You're mostly correct, but not completely. Closures "protect my variables from the outside" because my variables are declared on the functions scratchpad. our variables are declared on what could be considered the package's scratchpad.

      ------
      We are the carpenters and bricklayers of the Information Age.

      Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

      I shouldn't have to say this, but any code, unless otherwise stated, is untested

[reply]

        Perhaps I'm missing something, but I don't see what about my post was incorrect. Were you pointing out an error on my part, or just adding some more information?

[reply]
Re: "our" versus "my" for class data
by bgreenlee (Friar) on Aug 07, 2004 at 22:33 UTC

    That's the way I would do it. I wouldn't use 'our' for class variables because I tend to be fairly strict about my OO and believe that they shouldn't be accessed directly from outside the module (use some form of get/set methods if you need external access). And there aren't any memory leaks doing it either way, AFAIK.

    Brad

[reply]
Re: "our" versus "my" for class data
by adrianh (Chancellor) on Aug 07, 2004 at 22:45 UTC
    Is there any reason (other than to allow it to be set from outside the package) to change

    The only other reason I can think of would be if local-ising it would be useful. Otherwise my would be the best route IMHO.

[reply]
[d/l]
[select]
Re: "our" versus "my" for class data
by hv (Prior) on Aug 08, 2004 at 16:04 UTC

    You won't get memory leaks per se, but you may sometimes get tripped by the somewhat random order of destruction in final cleanup.

    This usually only makes a difference if your class data includes objects that have a DESTROY method, eg:

      sub DESTROY {
    my $self = shift;
    $self->{dbh}->disconnect if $self->{connected};
  }

    [download]

    In that example, during global destruction it is possible that $self->{dbh} has been destroyed before this object, in which case you'd get an error in that DESTROY.

    I often get around that problem with a simple:

      my $class_data; END { $class_data = undef }

    [download]
    .. which help to ensure things will be tidied up in an appropriate order by removing the need for perl to guess at a sensible order to destroy things.

    Hugo

[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom