Re: Detecting assignment event for AUTOLOAD'd lvalue subs ?

Sorry, I know this isn't addressing the root of your problem, but have you considered using Class::Std instead of AUTOLOAD? I've been going through 'Perl Best Practices' by Damian Conway, and he says there that 'AUTOLOAD() doesn't promote efficiency, conciseness, robustness, or maintainability, and is best avoided entirely'. In a nutshell, his reasoning is that if there are two or more AUTOLOAD() definitions, the second may be the one you want, but it would never get a chance to handle the method. I think he's implying that it makes it a headache to maintain and could introduce bugs into your code.

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....

Comment on Re: Detecting assignment event for AUTOLOAD'd lvalue subs ?

Replies are listed 'Best First'.
Re^2: Detecting assignment event for AUTOLOAD'd lvalue subs ? by renodino (Curate) on Feb 05, 2006 at 17:36 UTC
Let me start by saying I don't buy the inside-out thing, so I'd be disinclined to use Class::Std in the first place. (not a knock on Mssr. Conway, I'm heavy user of his excellent Text::Balanced module) 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.	[reply]

Replies are listed 'Best First'.

Re^2: Detecting assignment event for AUTOLOAD'd lvalue subs ?
by renodino (Curate) on Feb 05, 2006 at 17:36 UTC

not a knock on Mssr. Conway, I'm heavy user of his excellent Text::Balanced module)

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.

[reply]