Re: OO Perl Baby Steps

[Clovis_Sangrail]

Thanks, this is informative. I tested it out and saw that with "package pkgname;" just above the block of my parent class, I could move methods out to below the block of code and child classes could still inherit them. That's probably not a good idea. I guess the book's notation, with the package directive inside the block, is the most suggestive of the idea that the methods are specific to the class. That's probably what I'll stick with, and use 'package' statements outside of a block just for namespace (rather than OO Perl) purposes. But it's good to know about the new 5.14 syntax.

[jeffa]

Perl was not necessarily designed to be Object Oriented, and the addition of OO to Perl has been called by some a hack at best. If this concern of yours about packages is great enough then i instead invite you to use the declarative syntax for Moose, MooseX::Declare.

[Clovis_Sangrail]

I do want to check out Moose and MooseX (I'm tempted to call it 'Moose++'), it seems like alot of people use it. But I first want to get thru the, err, 'official' implementation of OO Perl as described in the Alpaca book.

As I was reading the book and got to the section on closures, I thought to myself: "Ahh, this is how they are going to do private variables in a class." Then it turns out that it doesn't work that way at all. The private data is just all the fields in the whatever-it-is that the blessed reference references. And some people complain that it isn't as really private as they'd like.

I'm surprised that there is not more use of closures. OTOH, maybe that would not work well with inheritance? In Googling about on the issue I see that I'm far from the first person to think about this. Well, exploring that question is likely much further over my head at this point than is Moose.

[tobyink]

Closures are totally workable as a basis for OO Perl...

#!/usr/bin/env perl

use strict;
use warnings;
use Data::Dumper;

{
    package Person;
    sub new
    {
        my $class = shift;
        my %store;
        bless sub
        {
            my ($action, $slot, $value) = @_;
            for ($action)
            {
                if (/fetch/)  { return $store{$slot} }
                if (/store/)  { return $store{$slot} = $value }
                if (/delete/) { return delete $store{$slot} }
                if (/exists/) { return exists $store{$slot} }
            }
            die;
        } => $class;
    }
    
    sub name
    {
        my $self = shift;
        @_ ? $self->(store => "name", @_) : $self->(fetch => "name")
    }
    
    sub age
    {
        my $self = shift;
        @_ ? $self->(store => "age", @_): $self->(fetch => "age")
    }
}

my $person = Person->new;
$person->name("Bob");
$person->age("42");

print $person->name, " is ", $person->age, " years old.\n";
print Dumper($person);

However, they're slower than the more usual blessed hashref storage, because a method call will typically involve at least two sub calls.

For some reason I feel compelled to produce a MooseX module allowing you to use blessed coderefs for Moose objects like the example above.

[jeffa]

I see two primary concerns here regarding OO: encapsulation and security. Perl does not provide acceptable security here, because to do so would be very un-Perl like. As someone who was trained on classic OO before he studied and used Perl, i have absolutely no desire to use that private or protected nonesense in my code, because i dislike the restrictions they impose on future hackers of my code.

Othewise i would use Java or Ruby or perhaps Perl 6 in 100 years ...