in reply to OOP By Any Other Name

Using a hash in that fashion is generally referred to as dispatching and the hash is a "dispatch table". Contrast the technique with more usual Perl OO:

use strict; use warnings; package Counter; sub new { my ($class, $start) = @_; return bless {count => $start}, $class; } sub add { my ($self, $value) = @_; $self->{count} += $value; } sub get { my ($self) = @_; return $self->{count}; } package main; my $ctr = Counter->new (7); print "Start: " . $ctr->get () . "\n"; $ctr->add (3); print "End: " . $ctr->get () . "\n";
True laziness is hard work

Replies are listed 'Best First'.
Re^2: OOP By Any Other Name
by Anonymous Monk on Feb 26, 2011 at 02:09 UTC
    But here one has encapsulation of data in %Internal... (a la Inside-out objects.) Downsides: @ISA isn't going to allow inheritance, not sure if closed methods take up more memory with each instance. Upside: I feel that it is syntactically cleaner than bless. But my feeling don't count for much.

      Ah, I wasn't sure just what aspect of the code you were most interested in. A more traditional approach to inside out objects goes something like this:

      use strict; use warnings; use Data::Dump; package Counter; my %data; sub new { my ($class, $start) = @_; my $lu; my $self = bless \$lu, $class; $data{$lu = "$self"} = {count => $start}; return $self; } sub add { my ($self, $value) = @_; $self = $data{$$self}; $self->{count} += $value; } sub get { my ($self) = @_; $self = $data{$$self}; return $self->{count}; } package main; my $ctr = Counter->new (7); print "Start: " . $ctr->get () . "\n"; $ctr->add (3); print "End: " . $ctr->get () . "\n";

      which gains the data hiding without losing Perl's normal OO support.

      The largest downside I see with the code you suggested is declaring all the anonymous subs in the constructor - that just doesn't scale well to anything other than toy code and is syntactically much nastier in my view.

      True laziness is hard work
        Declaring the anonymous subs in the constructor may make sense to someone who has a lot of JavaScript experience. At that point it isn't really much different than thinking of the constructor as the class definition. Which can scale perfectly well as long as you are used to it, and have support for the other niceties that people expect from OO code. (Like some notion of inheritance and composition.)
      ... not sure if closed methods take up more memory with each instance...

      They have to bind to the correct (and often unique) lexical environment, but that's about it.

      not sure if closed methods take up more memory with each instance

      There will be some table of pointers (a pad) so for captured and local lexicals. The opcode tree itself won't be duplicated.