in reply to Re^5: Experimenting with Lvalue Subs
in thread Experimenting with Lvalue Subs

It seems to me that you are viewing :lvalues as a C programmer would, something that behaves as a piece of memory. Wheras most people here are viewing lvalues as a VB or Java programmer would: disguised method calls. Maybe the solution is to provide both? I sure would like to have a way for 

$obj->method=$foo;

[download]
be the same as 
$obj->method($foo);

[download]

It would be nice if Perl automagically made 

$obj->method++;

[download]

be the same as 

$obj->method($obj->method()+1);

[download]

But it wouldn't bother me too much if it didn't.

The point here is that folk would be happy to forgo some of the more extreme uses of :lvalue subs like you and ysth post if they could just easily write validation code for the simpler cases. And we'd really like to do it in Perl 5. :-)

UPDATE: This was discussed in the CB and there seemed to be some agreement that there is room for the souped up, can do anything :lvalue as well as a more constrained :assignable version that has much simpler semantics. In fact it seems to me that the :assignable version could probably be implemented with :lvalue and better callbacks once Perl 6 is around tested and stable.

---
demerphq

Replies are listed 'Best First'.
Re^7: Experimenting with Lvalue Subs
by dragonchild (Archbishop) on Jan 25, 2005 at 14:32 UTC
    I sure would like to have a way for $obj->method=$foo; be the same as $obj->method($foo);

    Oh ... that just looks horrible. You're creating a syntax that has side-effects that aren't obvious from reading the code. Then again, the entire lvalue thing is ... it's just plain stupid, in my opinion. Function calls that, depending on if they're being assigned to, will behave one way or another. And, frankly, unless you bring a lot of outside knowledge to the table, you don't know which ones can do it and which ones can't.

    lvalue subs work in Javascript because Javascript is built to treat methods and attributes identically - it's a slot-based OO language like Self. And, I still have problems with the entire concept. It assumes that I, the programmer, don't need to know what is data and what is behavior. I may not want to know it at times, but I would certainly like to be able to know it, if I want to see the difference.

    Perl5 is not like Self. Perl5 is like C. Perl6 may be more like Self, in which case lvalue subs will be built into the language and they will work and they will work just fine. I have complete faith in Larry, Damian, et al that they will not screw this up. But, C does not have lvalue functions. C++ doesn't have lvalue functions.

    You know what - lvalue mutators just seem wrong to me. What's the client doing screwing around inside the object's internals? That's what lvalue mutators mean you to do ...

    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]
[d/l]
[select]

      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.

      ---
      demerphq

[reply]

        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.

        Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

[reply]
[d/l]
[select]
        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]

In Section Meditations