What stopped you from generating the methods when loading the module?

I can see why you'd perhaps want to delay creation of the methods if there are several hundreds of attributes and you might not use to many of them for each compilation. But you said you chose AUTOLOAD due to flexibility. What flexibility does AUTOLOAD give you that's not easily done without AUTOLOAD? It makes think you have indeterministic attribute names, or attribute names that are best expressed through a pattern. But you also say that you have a list with the attributes that are allowed for autogeneration. So it doesn't sound like it's that either.

In either case I'd prefer to have generic &set_value and &get_value methods instead, where the first argument is the attribute name. This would also allow you to easier give better diagnostics, and if there is a couple of hundred attributes I'd expect a typo or two every now and then. Furthermore, if I needed to initialize more than a handful attributes I'd prefer, if possible, doing something like

  my %attrs = (
    foo => 1,
    bar => 2,
    ...,
    baz => 50,
  );

  while (my ($attr, $val) = each %attrs) {
    $obj->set_value($attr => $val);
  }
[download]

over

  $obj->set_value_foo(1);
  $obj->set_value_bar(2);
  ...;
  $obj->set_value_baz(50);
[download]

or being forced to do some dynamic method lookup, e.g.

  my %attrs = (
    foo => 1,
    bar => 2,
    ...,
    baz => 50,
  );

  while (my ($attr, $val) = each %attrs) {
    $obj->${\"set_value_$attr"}($val);
  }
[download]

I really don't see the advantage of having an AUTOLOAD here. I just see disadvantages. Look at Re: is autoload bad style? for an explanation for my skepticism.

If you do want to pre-generate the methods there are modules for that on CPAN to make it even simpler for you.

Sorry, I should have explained better what the script does.

The script is a webserver that deals with the scheme of a directory service. At the starting of the program, the list is empty, and then with the first connection to the directory, the list is initialized according to the object classes and their settings (like attributes-names and their status (mandatory or optional), format, ...). The scheme of the directory changes sometimes, and the script will recognize these changements automatically and adapt the object interface methods to them.

The calls to these objects are generated by user input, so some objectclasses may not be used for a long time, while others are used very often.

And with autoload, I can get easy error messages if somehow an object interface method is called that is not allowed.

The problem with AUTOLOAD and inheritance is no problem in this case.

Best regards,
perl -e "s>>*F>e=>y)\*martinF)stronat)=>print,print v8.8.8.32.11.32"

I'm not sure I understand you, but continuous runtime redefinition of a class seems evil--especially as it seems like you easily can do without, but I may be wrong.

I read "object interface methods" as get/set methods. If I'm right in that I still don't see why you can't use generic get/set methods instead, and give the attribute/property as name. Then you wouldn't need to redefine the class, just some settings in the object. That would be much preferable to me.

The calls to these objects are generated by user input

I see that as an argument for having generic methods instead.

The problem with AUTOLOAD and inheritance is no problem in this case.

It's seldom a problem for you, the author of it. Instead, it may become a hazzle for whomever that decides to subclass your class.

And with autoload, I can get easy error messages if somehow an object interface method is called that is not allowed.

Why would that be easier? You can just define a list with allowed attributes, and then check against that in the get/set methods. In autoload you much first check so that it indeed is a get/set method, otherwise die with a missing method error message. And then you much do the check I just mentioned anyway.

I can't stop thinking that I've completely misunderstood you, but I fail to make any other plausable interpretation.

ihb