Detecting assignment event for AUTOLOAD'd lvalue subs ?

renodino has asked for the wisdom of the Perl Monks concerning the following question:

I'm seeking some insight, and maybe some code snippets, on how to mingle lvalue subs and AUTOLOAD. I've reviewed Experimenting with Lvalue Subs and peeked at Want, and a few other things Super Search turned up, but can't seem to find the right bits.

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};
}
[download]

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 ?

Update:

Given the deafening silence, it appears I've either

Stumped the experts
committed an egregious faux pas

(maybe both).

However, upon further reflection, this issue is a bit thornier than I realized...

If the proxy object is in fact threads::shared, then its members must likewise be either scalars or threads::shared. If the members are threads::shared, then the proxied object could automagically see the lvalue assignment. So perhaps the solution is to use threads::shared refs (incl. for scalars) and thus the proxied object receives the goods wo/ any need for notification.

However, since the client proxy can be shared by multiple threads, and hence the lvalue could be concurrently updated/read by multiple threads, there needs to be some locking added...

All in all, it may be a bad idea...or at least an idea whose time has not yet come. Perhaps Perl6 or Ponie will address this by relaxing the "can't tie a threads::shared" requirement.

FWIW: My original purpose was to create a variant of DBIx::Threaded that replaces the non-shared, tied client proxies with threads::shared, untied versions, in order to simplify and speed up the passing of proxy dbh's/sth's between threads. The current version has to do a lot of marshalling/unmarshalling when the proxies are passed around. If the proxies were made threads::shared, passing them around would be faster/simpler.

So if "DBIx::Threaded::Untied" replaced DBI's tied members (e.g., AutoCommit, PrintWarn, RaiseError, etc.) with lvalue subs of the same name, the impact on code would be a bit less painful, e.g.,

$dbh->{AutoCommit} = 1;
[download]

becomes

$dbh->AutoCommit = 1;
[download]

Comment on Detecting assignment event for AUTOLOAD'd lvalue subs ? Select or Download Code

Replies are listed 'Best First'.
Re: Detecting assignment event for AUTOLOAD'd lvalue subs ? by bowei_99 (Friar) on Feb 05, 2006 at 17:04 UTC
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....	[reply]
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]