I'm using AUTOLOAD to provide a client proxy wrapper for apartment threaded objects. All works well for the usual behaviors, and I think I've worked out how to handle proxied closures. I'd also like to be able to handle proxied lvalue subs as well, but can't quite figure out how to trap the actual assignment event so it can be propagated back to the proxied object. I don't want to use tied objects, since the client proxy objects are usually threads::shared (to make it easy to pass them between threads).
So, assuming the proxied object has
sub proxiedMethod : lvalue {
my $this = shift;
$this->{_value};
}
and assuming the proxied object knows how to tell
its proxy that proxiedMethod() is lvalue, and the proxy's AUTOLOAD()
uses WANT('LVALUE') to test if the method is being used as lvalue,
how can the proxy be notified of any eventual assignment, so that it can
pass the value back to the proxied object ?
Well, I can see value in what he's saying, but I know that every situation is different, e.g. it might be too hard to refactor the code at this point, etc. I get the sense your case may be one of these, but just thought I'd bring it up....
That being said, Thread::Apartment's use of AUTOLOAD is very focused: its simply a way for client proxies to handle any method an invokant might call, without forcing the proxied object to explicitly install every exported method into the proxy. I had originally considered the latter approach, but soon realized that for some legacy modules (e.g, Perl/Tk), it might be nearly impossible to enumerate all the methods. Note that Thread::Apartment does permit the proxied object to explicitly declare its exported methods to the proxy, but also permits a "wildcard" to permit arbitrary method calls, which can be rejected by the proxied object as needed.
I'd also argue that AUTOLOAD has proven useful to simplify mapping to Web services (see Net::eBay).
However, using AUTOLOAD in an inheritance hierarchy is probably asking for trouble.