|
in reply to Re^7: Experimenting with Lvalue Subs
in thread Experimenting with Lvalue Subs
You're creating a syntax that has side-effects that aren't obvious from reading the code.
I cant think of any situation where I want a user to be able to have set access to a property of my object and not have side effects. It seems a simple rule, if you are assigning to a method that there will probably be side effects.
It seems to me that your expectations are completely in line with current :lvalue subs, do you find them useful? I certainly dont, and it seems to be a general consensus of folks who write a lot of perl that :lvalue subs as currently implemented dont solve a problem any of us need solved, wheras there seems to be a general consensus that such an equivelency as I mention is exactly what we want. To many of us it seems bizarre that VB and Java both provide easy ways to have validatable assignable methods and Perl doesnt.
I think juerd has posted a number of examples of where such behaviour would be very useful indeed. Hopefully he will reply with a link.
|
Re^9: Experimenting with Lvalue Subs
by Juerd (Abbot) on Jan 25, 2005 at 22:55 UTC
|
I think juerd has posted a number of examples of where such behaviour would be very useful indeed. Hopefully he will reply with a link.
Just think of anything you can do with a variable, but cannot do with a value returned by a sub.
Variables are really powerful in Perl because they are mutable. While other languages disagree that this is a good thing (Python, for example, has immutable variables - only assignment can change a value), we should stick to the Perl idea that this can actually be put to great use.
Variables are variable, and that's where they excel. Some examples of what you can do on lvalues, but not on rvalues:
But really, my favourite:
- you can take a reference and pass that, re-use that, etcetera!
To extend it to Perl 6, I'll explain how "." and ".=" work in P6: "." is used for method calls and dereferencing, as with "->" in Perl 5. ".=" is like Perl 5's ".=", except "." doesn't concatenate strings. If this is too vague, let one example be sufficient to explain what I mean: @array.=sort; does the same as @array = @array.sort, but possibly more efficient. No more need for LHS detection hacks like with the optimization for @array = sort @array; in Perl 5.
The expressiveness, flexibility and efficiency of lvalue operations must not be undersestimated.
| [reply]
[d/l]
[select] |
Re^9: Experimenting with Lvalue Subs
by dragonchild (Archbishop) on Jan 25, 2005 at 15:09 UTC
|
It seems to me that your expectations are completely in line with current :lvalue subs, do you find them useful?
My reply, from the post you're replying to, would be:
Then again, the entire lvalue thing is ... it's just plain stupid, in my opinion.
I don't know of any benefit to having lvaluable subs that either
- doesn't break OO encapsulation
- obfuscate the intent of the programmer
Of course, and as always, I would be delighted to be proven wrong.
Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.
| [reply] |
|
|
$obj->hashlikeproperty($key)=$value;
$obj->scalarlikeproperty=$foo;
$obj->flexibleproperty=(1..10);
$obj->flexibleproperty=5;
and have them be some sensible equivelent method call. Id say that few of us care if we can use such a sub as a slot in a list assignment, or if we can take a ref to the "value" the property represents or if we can localize it (how the hell you localize a change that may have massive sideffects is beyond me). We dont care about weird stuff like that much, we dont even care much if $o->prop++ gets translated to two method calls. (If we were really concerned about such things we probably wouldnt be using Perl at all.)
We want the side effects, we want validation, it would be nice if we could handle list and scalar assignment in a single sub, but bottom line we just want the syntactic sugar and we really dont want to have to create ties for it every time. In fact it seems to me that ties arent even appropriate as there isnt any efficient way via a tied interface to do things like set a full array in a single go, instead it gets translated into zillions of STORE calls. Hmm, actually thinkign about it further i can imagine cases where a tied approach flat out wont work at all. How do you do something like
$obj->average=(1..10); #assign 5.5 as the average
$obj->average=2.5; #assign 2.5 as the average
With a tied/lvalue interface?
| [reply]
[d/l]
[select] |
|
|
First off, you are assuming that an lvalue sub has to expose an actual attribute of the object.
Which is understandable as with the current P5 implementation and the proposed P6 implementation, where you cannot do anything after the assignment takes place--you are right.
But now imagine that the method was passed the rvalue when the method was invoked. Now you can do anything with it, like validate it, but also use it to derive some other value or a whole collection of values that then are then assigned to attributes of your object--none of which happen to have the same name as the method invoked.
The desirable feature is not the direct access to the underlying entity, it is the syntax that allows:
$obj->thing++;
in preference to
$obj->set_thing( $obj->get_thing() + 1 );
Whether thing is actually a piece of ram within the object or a conceptual attribute of it is secondary.
Equally, whether that example has to "call the function twice", once to get the value and once to modify it, is an implementation detail that should be transparent.
Examine what is said, not who speaks.
Silence betokens consent.
Love the truth but pardon error.
| [reply]
[d/l]
[select] |
|
|
