Modules for autogenerating accessor/mutator methods

[srdst13]

There are a plethora of modules for auto-generating accessor/mutator methods including Class::MethodMaker, Class::Struct, Class::Accessor, and several others. I've been through the documentation of the first three and just wanted to hear what people thought of each. Are there strong reasons (or any reasons, for that matter) for using one over the next? Are there others that one "must" consider?

Thanks,
Sean

[other90percent]

Accessor generation is very handy when you've got a 'big' object model sketched out - the nouns of your application - and you'd like to flesh out that model quickly in Perl, so you can get on to how those objects interact. It's also good coding practice to reduce redundant code, and accessor/mutator generation helps quite a bit there.

I've used Class::Accessor several times, and it's pretty easy-going. It's very good for cases where you have many classes to implement, and they're all fairly similar (in the since that they are all composites of each other or simple scalar datatypes). It's easy to have validating mutators. Class::Accessor is also nice about not getting in your way; if you want, you can use it to generate only some of your methods, and hand-code the "interesting" ones yourself.

Class::Accessor can also be used on-the-fly (at runtime) to add new methods, though most people won't need such a fancy trick. Just call $obj->mk_accessor() and you can add bells and whistles as needed. But most object models don't need to go around redefining their schemas.

Class::MethodMaker, Class::MakeMethods, and many other approaches want to be compile-time only, which might be "safer", or at least "saner". In other words, you define your classes in like this (varies a bit):

use Class::MyFavoriteMethodGenerator qw( YOUR-CLASS-DEF-HERE );

where YOUR-CLASS-DEF-HERE is usually a hash of attribute names and options (read-only, etc).

Class::MakeMethods is much more ambitious about generating more complex methods for you, while trying to keep your class definition code as simple as possible. Try it, and see if you like it.

[Ovid]

There's also Class::Meta. For most applications it's overkill. However, if you need introspection (think "Reflection" if you're a Java guy), then Class::Meta is a great choice.

[simonm]

I think this comes down to the kinds of accessor methods you need created.

If you just need a few basic get/set methods, than any of these choices would be fine and I'd pick the simplest or the most popular.

However, if you are generating a lot of different kinds of methods, you may need to base the decision on the types supported by each system.

My own Class::MakeMethods supports hundreds of different method types, so if you're in the market for inside-out accessors, or accessors for array-based objects, or accessors which return closures that perform their action, or something else a bit out of the ordinary, it's worth wading through the volumnious documentation.

[wazoox]

I'll even add to your question: is there any reason not to write accessors/mutators ourself?

[tlm]

Laziness?

[srdst13]

Hey, that was my answer! However, these modules exist and are definitely being used. Class::DBI is a prime example. I really don't get much out of writing simple accessors/mutators. If they get more complicated, I would of course like to have the Module move over and facilitate my creating a custom method, which most seem to offer as an option. I think the question still stands as to which, if any, is "better" than the next (or what less-than-obvious advantages exist in one versus the next).

Sean

[wazoox]

Really I'm not sure. An accessor/mutator is often very simple, so where is laziness? writing the quick'n'dirty one that "just works" or use a complex module that provides complex options and try to learn how it works --and may bite?

[brian_d_foy]

When a lot ( > 2 ) of your subroutines have the exact same code, why type it more than once? :)

Other than that, some things generate lots and lots of accessors. Writing some code to automatically generate them all means less typing and a single point of maintenance when you decide you need to change them all.

[magog]

I'll even add to your question: is there any reason not to write accessors/mutators ourself?

Because then we would also have to write tests for them.

Michael

[wolv]

Attribute::Property is very elegant and simple. I like it mainly because it adds so little typing, instead using Perl's attributes to make any sub a property (accessor).

package Automobile;

sub new : New;
sub colour : Property;
sub owner : Property { /^(?:Jack|Jill|Bob)$/ }

package main;

my $car = Automobile->new(colour => "red");
print $car->colour; # red
$car->colour = "blue";
print $car->colour; # blue

my $other_car = Automobile->new(owner => "Jack"); # works
my $another_car = Automobile->new(owner => "Dad"); # fails

[TheDamian]

Are there others that one "must" consider?

Well, there's certainly no must about it, but I'd encourage you to look at my new Class::Std module, as well as Abigail's Lexical::Attributes.

Damian

[johnnywang]

There were a couple of blogs with titles like "getters/setters considered harmful for python/php". The authors were proposing to access the member variables directly, unless one wants to add some logic like validation. That, of couse, breaks encapsulation. Any comments?

[magog]

The blogger agrees that you should make your object's data available to the outside world in a way lets you change the underlying implemtation when you need to.

In Java, it seems like the "best practice" is to copy and paste a bunch of identical get/set methods.

The blogger seems to be against copying and pasting when native language features can give you the same benefit. With Python (apparently) you can use the built-in features to make public attributes that can be transparently upgraded from simple attributes to get/set methods, without changing the API:

    contact.email = "[e-mail]"

Behind the scenes this can be implemented by a simple attribute variable or a get/set method. The user of the object doesn't care.

This feature isn't built in to Perl 5. If you break encapsulation and access the underlying hash keys directly:

    $contact->{'email'} = "[e-mail]";

Then you can't protect the access without a tied hash. On the other hand, if you wrap the accessor in a method:

    $contact->email("[e-mail]");

Then you have to copy and paste multiple identical get/set methods.

The better solution is to let a module generate the methods for you. For instance, Attribute::Property (which looks excellent, BTW - thanks for pointing it out, wolv!), automatically makes methods that are assignable like hash elements:

    # module code
    sub email   : Property;

    # ...

    # user code
    $contact->email = "[e-mail]";

When you need to upgrade 'email' to do some validation, you can change the accessor into a full sub:

    # module code
    sub email {
        # do some validation or processing here
    }

    # ...

    # user code - API stays the same.
    $contact->email = "[e-mail]";

Michael

[wolv]

Mind you, Attribute::Property generates lvalue subroutines, so a simple 'sub email { }' won't replace the interface in a compatible way. Furthermore, A::P supports adding validation and processing: sub email : Property { process; validate } The return value of the block will indicate whether the value given validates.

[ambrus]

If you need objects, use Ruby. It has efficent accessor/mutator generating methods built in, called attr, attr_reader, attr_writer, attr_accessor in the Module class.