Well, my French is very poor, but I think I understood the essential parts, and if there's written what I understood, I like it.

There are other interesting possibilities, e.g. creating an anonymous subroutine and write it into symbol table, e.g.

  my $code = sub {
    # for a better way, see Tanktalus' post below
    my ($self, $value) = @_;
    $self->{$attname} = $value if defined $value;
    return $self->{$attname};
  };
    
  no strict 'refs';
  *{$attname} = $code; # put it into symbol table
  use strict 'refs';

  return $self->$code(@params);
  # or: goto &$AUTOLOAD;
[download]

my @attributes = qw(color speed);

# generate the methods
foreach my $attribute (@attributes) {

  my $code = sub {
    # for a better way, see Tanktalus' post below
    my ($self, $value) = @_;
    $self->{$attribute} = $value if defined $value;
    return $self->{$attribute};
  };

  no strict 'refs';
  *{ $attribute } = $code;

} # foreach
[download]

This is where getting perl to do it in perl 6 is going to be cleaner...

$obj->color(undef);
[download]

Does this set the color to undef? Perhaps you mean:

  my $code = sub {
    my $self = shift;
    $self->{$attribute} = shift if @_;
    $self->{$attribute};
  }
[download]

(Falling off rather than returning is just a tiny bit faster according to the benchmarks I've done in the past.) Here, if you pass anything in, it'll get set, but we won't set to undef if you don't pass anything in. Your original is ok if undef is the sole invalid value. That is actually more rare than some people may think - in true perl fashion, by allowing anything, you leave your code more flexible. The primary exceptions are generally external standards, and, even then, should only be when you're outputting them, not interpreting them on input. That is, be conservative in what you send (stick to the letter of the standard), but liberal in what you receive (allow variations on the input). For get/set methods, I find it extremely rare that I don't want the ability to set a variable to undef to signify its invalid or unknown state. For example, setting color to undef simply means that, at this point in the program, I don't know the color, even if I thought I did earlier.

Yep, this have the advantage to avoid AUTOLOAD. But consider the following point: If you put my AUTOLOAD method in a module called AutoAccess, you just have to write something like

package Foo ;

use base qw/AutoAccess/ ;

sub new{
  bless { 'a1' => undef , 'a2' =>undef } , shift ;
}

1;
[download]

To have the benefits of the auto accessors. The methods 'a1' and 'a2' are implemented 'on demand' to use the nowadays buzzword :) If you'd like to change the implementation and want to keep the behaviour of the class from the user code point of view, you just have to implement by hand the concerned accessor methods. Anyway, I also think that explicitely write which attribute should be concerned by auto accessor generation can be a good thing. Specialy to write code that don't look too magic to new readers :) Is there a way to use the 'my @attributes = qw(color speed);' method in a factorized way ?