|The stupid question is the question not asked|
Experimenting with Lvalue Subsby Limbic~Region (Chancellor)
|on Jan 24, 2005 at 17:58 UTC||Need Help??|
Lvalue subs are experimental. It says so right in perldoc perlsub. They have been experimental since their introduction in 1999, nearly 6 years ago. Everytime someone asks how to do argument validation with lvaluable subs, the mantra is "lvaluable subs are experimental and shouldn't be used, there are modules that likely do what you want already, but if you must do that then you will need to tie the return variable which is going to make it slow".
While not exactly the same, this is similar to the response about using map in a void context. Readability issues aside, the efficiency problem turned out to be a 3 line patch. I feel like the same thing is happening with Lvalue subs and am interested in what you think. Consider the following snippet:
It allows me to use a single accessor/mutator method. Of course, the same thing could be done as
$obj->get_set('name' => 'Limbic')
but some people really prefer the assignment notation. So what's the problem? Well, first I might want to restrict what keys can actually be set. Borrowing a trick from Zaxo, you can do this with the current Lvalue implementation:
While this will silently doesn't do what you asked, it could be made to be verbose but it still doesn't allow you to validate the rvalue. It isn't on the @_ stack. In fact, as far as I know, there is no way to get to the rvalue inside an Lvalue sub. Have given this some thought, discussing it in the CB, thrown out some possible implementations, I think there are only a couple of things that are necessary to make Lvalue subs more useable.
Of course there are a few other things that might make them nicer. A straight forward alternative to using a $junk variable and ternary to avoid assignment if validation fails would be nice. I would imagine that you could manipulate the rvalue(s) prior to the assignment, but it might also be nice to have pre and post hooks for syntatic sugar purposes.
I am not saying that these changes would only be 3 lines but is that any reason not to make them more useable? When I mentioned in the CB that the problem was having a competent C programmer write the patch and then having the fortitude to fight for it on p5p. The response from a monk who has been around the Perl community for quite some time and has been involved with p5p indicated the real problem was the latter not the former. I find this hard to understand. If there is no currently promised behavior and someone provides a working patch to make it useable, why not apply it?
So what do you think - about extending Lvalue subs at all, about the difficulty in doing so both from a C perspective as well as getting the patch applied, about what features and implementation would really make it worth the effort?
Cheers - L~R