Re: "Fields" for "Objects"

[Transient]

At the bottom of perltoot there is a nice way to use AUTOLOAD to generate the getters and setters for your objects. (The following code is directly from the link):

package Person;
    use Carp;
    our $AUTOLOAD;  # it's a package global

    my %fields = (
        name        => undef,
        age         => undef,
        peers       => undef,
    );

    sub new {
        my $class = shift;
        my $self  = {
            _permitted => \%fields,
            %fields,
        };
        bless $self, $class;
        return $self;
    }

sub AUTOLOAD {
        my $self = shift;
        my $type = ref($self)
                    or croak "$self is not an object";

        my $name = $AUTOLOAD;
        $name =~ s/.*://;   # strip fully-qualified portion

        unless (exists $self->{_permitted}->{$name} ) {
            croak "Can't access `$name' field in class $type";
        }

        if (@_) {
            return $self->{$name} = shift;
        } else {
            return $self->{$name};
        }
    }

Which is basically going to "auto build" anything that's set in your permitted hash. I've used this before and it's saved a great deal of time (and tediousness).

I know this is a different approach than what you asked for (i.e. a specific module), but I hope it helps. It also combines your calls for get/set into a single method.

[stvn]

Honestly, use of AUTOLOAD for this kind of stuff is just really a bad idea. You will outgrow this solution all too quickly, not to mention the fact that your code is broken once you introduce inheritance since you have no mechanism to inherit the fields. Sure that problem is solve-able but not without a bunch of tedious plumbing as well. It should also be noted that AUTOLOAD introduces something like a 400% performance penalty over normal method calls (which only gets bigger the more complex your AUTOLOAD gets).

[shmem]

It should also be noted that AUTOLOAD introduces something like a 400% performance penalty over normal method calls

That penalty can be avoided for every but the first call to the autoloaded setter/getter function, if the AUTOLOAD block generates a subroutine living in a typeglob, just as AutoLoader does:

sub AUTOLOAD {
    my $self = shift;
    my $type = ref($self)
        or croak "$self is not an object";

    my $name = $AUTOLOAD;
    $name =~ s/.*://;   # strip fully-qualified portion

    unless (exists $self->{_permitted}->{$name} ) {
        croak "Can't access `$name' field in class $type";
    }
    my $sub = sub {
        my ($self,$value) = @_;
        $self->{$name} = $value if defined $value;
        $self->{$name};
    };
    {
        no strict 'refs';
        *{$name} = $sub;
    }
    goto $sub;
}

Each subsequent call to the method accesses the sub normally, i.e. through typeglob lookup.

not to mention the fact that your code is broken once you introduce inheritance since you have no mechanism to inherit the fields. Sure that problem is solve-able but not without a bunch of tedious plumbing as well.

That plumbing amounts to writing a proper import() subroutine which calls AUTOLOAD for the inherited fields and exports them to the inheriting class. But then, you're right, why reinvent the wheel (there are reasons, though) if there are plenty modules out there which handle that. There's Moose, classes, Class::Accessor, ...

[stvn]

Each subsequent call to the method accesses the sub normally, i.e. through typeglob lookup.

Yes, this is true, however this is going deeper down the slippery slope where the amount of complex code to maintain is far outweighing the benefits of saving some typing. Take for instance, stack traces. Because you assigned an anon sub ref into a typeglob any stack traces will see the name of this method (and any other ones you created with AUTOLOAD) as simple __ANON__, which means you have no way of distinguishing them from one another. While this might not seem like much of an issue to some, it is a small details that would really be helpful when your up against the wall trying to fix a bug in the 11th hour.

Of course, this too is solveable, Ovid had a hack where he assigned a name to the __ANON__ typeglob slot using local I don't recall the details, and there is also Sub::Name on the CPAN. But either way your now depending on an XS module (Sub::Name) or doing some weird and nasty local/typeglob hackery.

That plumbing amounts to writing a proper import() subroutine which calls AUTOLOAD for the inherited fields and exports them to the inheriting class

Yes, but it wouldn't be that simple if you add in multiple inheritance and the possibility of conflicts/diamond inheritance. Also I am not sure how this would work for deeply inherited fields (more then one level away), but perhaps I am just not understanding the solution fully. Again, all might be solvable problems, but now you've gone from "saving myself some tedious typing" to "building my own object system with AUTOLOAD".

But then, you're right, why reinvent the wheel (there are reasons, though) if there are plenty modules out there which handle that.

The single best reason to re-invent the wheel is to do it as a learning tool. I highly recommend the practice, especially if you have other well written versions to learn/steal from. Moose would not exist if it were not for CLOS and more specifically the Art of the MetaObject Protocol book.

[dekimsey]

The only good reason to use AUTOLOAD is when you already know you need to use it. It has a magic-from-afar type behavior that can be weird.

[lodin]

I second stvn.

Since you know which fields are permitted when the class compiles you can generate them and get rid of AUTOLOAD. AUTOLOAD is really only needed when you do not know which methods the class will need to handle.

my @fields = qw/
  name
  age
  peers
/;

for my $name (@fields) {
  my $code = sub {
    my $self = shift;
    $self->{$name} = $_[0] if @_;
    return $self->{$name};
  };

  no strict 'refs';
  *$name = $code;
}

Now your class acts exactly like it would have acted if you manually wrote the methods, and you pay no run-time penalties.

Note how simple the logic of the code is compared to AUTOLOAD. And the AUTOLOAD implementation will get more complicated still. Consider what happens when you

• do $obj->can('age'),
• refactor and create a superclass that also uses AUTOLOAD, or
• use multiple inheritance where another class also uses AUTOLOAD.
• (Or forget to do return if $name eq 'DESTROY';.)
A proper implementation of AUTOLOAD requires an awful lot of thinking, and still it does not buy you anything, rather the opposite, if you already know the method names.

lodin