in reply to Using closures to achieve data hiding in OO Perl

You have it backwards. If you want to use closures cleanly and effectively, it's the inner layer of the methods that need to be a closure. 
package UsesClosures;

sub new {
   my $attr;

   return bless({
      get_attr => sub {
         $attr
      },

      set_attr => sub {
         $attr = $_[1]
      },

      some_method => sub {
         print "$attr\n";
      }
   }, shift);
}

sub get_attr    { &{ shift->{get_attr   } } };
sub set_attr    { &{ shift->{set_attr   } } };
sub some_method { &{ shift->{some_method} } };

[download]
my $o = UsesClosures->new();
$o->set_attr(123);
print $o->get_attr();
$o->some_method();

[download]

Your Dinner module would be: 

package Dinner;

sub new {
   my $hands_clean = 1;

   return bless({
      wash_hands => sub {
         $hands_clean = 1;
      },

      eat_food => sub {
         die "Filthy\n if !$hands_clean;
         print "Om nom nom\n";
      },
   }, shift);
}

sub wash_hands { &{ shift->{wash_hands} } };
sub eat_food   { &{ shift->{eat_food  } } };

[download]
my $dirtyeater = Dinner->new();
$dirtyeater->wash_hands();
$dirtyeater->eat_food();

[download]

Like inside-out objects, such objects are hard to debug.

Replies are listed 'Best First'.
Re^2: Using closures to achieve data hiding in OO Perl
by saurabh.hirani (Beadle) on Jun 13, 2009 at 05:10 UTC

    That is a much better way to use closures. Rather than accessing the method through, $obj->{'key'}->(), it makes more sense to do it the way you've posted. Thanks. Interesting comment that one, about closures being hard to debug. In a big application, data hiding can come at a cost.

    How often do you guys use closures? I mean, there are certain obvious places where closures can help like callbacks. I've never used closures. Never felt the need to. But citing from your experience, are there any other places where using closures is a good idea?

[reply]

      I use closures all the time. But never explicitly for data hiding (although it can come as a byproduct). Closures especially when coupled with eval, makes for an extremely powerful approach to solving problems, optimizing, simplifying design, and providing encapsulation. Using closures you can basically avoid OO, and do things that are extremely inefficient to do via OO techniques (especially in perl where method calls are slow). In fact I'd argue that closures are generally speaking more useful than OO.

      Go and get yourself a copy of Higher Order Perl by dominus. Its one of the better Perl books out there, and its almost all about using closures.

      Note: I updated this node by changing the previous link to mjd to the correct dominus.

      ---
      $world=~s/war/peace/g

[reply]
        Go and get yourself a copy of Higher Order Perl by dominus. Its one of the better Perl books out there, and its almost all about using closures.

        Thanks for the link. It looks interesting. Will definitely read it.

[reply]

      I didn't say closures were hard to debug, and I don't think that's true in most cases.

      What's difficult to debug are objects that hide their attributes. You can't dump them (fixable) or inspect them in a debugger (not fixable).

      In C, private attributes are hidden by denying code access to them. The debugger isn't subject to those access restrictions, so it can access private attributes just as easily as public ones. In Perl, the attributes aren't simply hidden. They are fundamentally different than public attributes. In a sense, they're not even in the object. (In inside-out objects, they truly aren't in the object at all.)

      So what has no cost in C has a great cost in Perl.

      How often do you guys use closures?

      Often (but never for the purpose you propose). I worked on a VB project recently, and closures were what I missed the most.

[reply]

In Section Meditations