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