Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Re: $foo->bar = 14;

by sauoq (Abbot)
on Dec 29, 2002 at 20:48 UTC ( #222954=note: print w/ replies, xml ) Need Help??


in reply to $foo->bar = 14;

This must be one of those hundredth monkey things. I was just having a discussion with BrowserUk yesterday about lvalue closures. I was going to write it up and ask if anyone was actually using them for anything useful. Maybe I still will after I put some more thought into it.

The contrived example I was working with was a settable counter that would increment when accessed. Using an lvalue closure resulted in nicer syntax than a closure which returns a reference. Returning a reference allows the value to be settable but it also requires dereferencing when you just want to use the value and that's pretty yucky. Of course, there are other ways to do it too, such as a tied scalar.

It seems to me that, although really neato, it doesn't provide a whole lot outside of some slimmer syntax. I think the cases where the syntax is significantly leaner (such as your $foo->bar =~ s/foo/bar/ example) are probably pretty rare.

Given the experimental implementation of the lvalue attribute, I won't use it in production code. Right now, it's a toy to play with. I'm still undecided as to whether (or how often) I'd use it if it weren't experimental.

-sauoq
"My two cents aren't worth a dime.";


Comment on Re: $foo->bar = 14;
Download Code
Re: $foo->bar = 14;
by tadman (Prior) on Jan 02, 2003 at 19:55 UTC
    I've been very lvalue-oriented for some time now, and I don't see anything wrong with the lvalue feature that would prevent you from using it in production code. It works just as you'd expect, though you have to use it properly.

    The reason it's probably considered experimental is likely because it's not fully implemented, as in, to the logical conclusion of what an lvalue-function should be. While the basic functionality seems rock solid, there's limitations to what you can do with it, such as performing data validation. The current take on the lvalue problem is likely to be deprecated and/or eliminated in Perl 6, but then again, a lot of things are, so I'm not worried.

    One of the benefits of using subroutines instead of direct hash access is that you can catch typos easily. If you assign to $self->{elemnent} you're missing the mark quietly, but a call to $self->elemnent will outright fail.

    I think it's a mistake to confuse "experimental" as a synonym for "doesn't work properly yet".
      I think it's a mistake to confuse "experimental" as a synonym for "doesn't work properly yet".

      I agree. I use it as a synonym for "is subject to change without warning." However unlikely, I don't want an unexpected change in an experimental feature to break production code. I like to think of that as being prudent though some might describe it as being paranoid. In any case, my operational experience has taught me that "experimental" and "production" don't mix.

      -sauoq
      "My two cents aren't worth a dime.";
      
      I think it's a mistake to confuse "experimental" as a synonym for "doesn't work properly yet".

      For me experimental means:

      1. Might have bugs - probably not true for :lvalue, the current implementation seems pretty solid
      2. Might change in a non-upward compatable manner - more likely for :lvalue if it is going to be of much use
      3. Might not be the "right" way of doing it - in my opinion the current :lvalue opens up your object implementation details far to much and is not the "right" way :-)

      I would not use :lvalue in production code because of (2) and (3). See lvalue considered harmful... where I go into this in more boring detail :-), and a suggestion for how I would like it to work.

      One of the benefits of using subroutines instead of direct hash access is that you can catch typos easily. If you assign to $self->{elemnent} you're missing the mark quietly, but a call to $self->elemnent will outright fail.

      I agree, but I think the disadvantages of :lvalue more than outweigh this advantage (and there are other ways to get around typos - e.g. inside out objects or Tie::SecureHash.)

        I think the aversion to using lvalue subroutines is cultural. I'm quite used to putting data, any data, into a C struct, or a C++ class object. You can shoot yourself in the foot, of course, but that's why you have to be careful.

        At least superficially, lvalue subroutines feel a lot more like they're real, tangible things, and not some fleeting whim of a hash key. Yes, you can put in bad data, yes you can break things, but putting rubber pads on the edge of all of your functions does not make them safe. It's just defensive programming, which in many cases is dangerous if over-done.

        As far as I can tell, lvalue works fine now, and when it's replaced with something better in Perl 6, which surely it will be, then there's no reason not to upgrade.

        One could just as easily argue that Perl 5 is experimental. Your points 1, 2, and 3 all apply to the same degree.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://222954]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (7)
As of 2014-08-28 00:35 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (253 votes), past polls