in reply to Use method/function signatures with Perl

I think the entire idea of rvalue accessor methods is flawed, now that we have the possibility to create lvalue ones. Since years ago, I have made programming much easier for myself by inventing some very simple rules:

Why should they behave like variables? Because in Perl, variables are powerful. They are lvalues, and they can be modified efficiently without copying the values. But mostly because they ARE variables, and as much as I like using black boxes with no knowledge of the internals, I do not wish to hide that these things are variables. Hiding that takes away a lot of power that lies in how Perl's variables work. To have this power without providing an lvalue interface, you'd need to create a method for every operator and function that uses lvalues.

Value validation used to be a good reason not to use lvalues. But there is Attribute::Property now. Not that I use it myself, though: sub foo : lvalue { shift->{foo} } (or sub foo : lvalue { $foo{+shift} } for inside-out objects) has proven to work very well, and value validation is something I don't do much (I expect people to RTFM). 

$person->name;         # get the name
$person->name("Ovid"); # set the name

$person->name(do { (my $temp = $person->name) =~ s/Ovid/Juerd/; $temp 
+});

$person->name($person->name . "\n");
$person->name(do { chomp(my $temp = $person->name); $temp });

[download]
$person->name;
$person->name = "Ovid";

$person->name =~ s/Ovid/Juerd/;

$person->name .= "\n";
chomp $person->name;

[download]

This still throws values in @_ away. But as idiomatically this syntax is used without any parentheses at all, that is not a problem.

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

Replies are listed 'Best First'.
Re^2: Use method/function signatures with Perl
by tilly (Archbishop) on Dec 06, 2004 at 22:47 UTC
    And I strongly disagree with you on the value of lvalue subroutines.

    As you indicate, you're throwing away the possibility of value validation. Whether or not you currently do any value validation, it is important to me to have the option. (If for no other reason than the fact that you can retroactively add it to help track down bugs.) Furthermore I take objection to being told that my programming practice is flawed because of a disagreement like this.

    Saying that you can use attributes to get value validation back doesn't comfort me. As I've repeatedly noted, I avoid attributes because the CHECK method may not be run for modules in my environment. So offering a buggy solution to replace a non-solution doesn't comfort me.

    I really like Ruby's compromise. You have the methods bar and bar= that can do anything they like. If they do what the names suggest then foo.bar acts like an lvalue. The language has a syntax that makes autogenerating (very effient and barebones) versions of these trivial. But you can do whatever you want.

    However in Perl I'll continue to use rvalue accessors, thankyouverymuch.

[reply]

      As you indicate, you're throwing away the possibility of value validation.

      As I indicate, Attribute::Property takes that argument away. You may not like that it is implemented as an attribute, but never did I say that lvalues imply throwing away the possibility of value validation. If anything, I said that it used to be harder without A::P. As with any lvalue in Perl: you can validate it as long as you don't fear tie. For $foo this hasn't been a problem, but for $object->foo some people do object. 

      package main;

{
    my $foo;
    sub foo {
        if (@_) {
            my $new = shift;
            # validate
            return $foo = $value;
        }
        return $foo
    }
}

      [download]
      I have yet to see code like this. And fortunately so.

      Saying that you can use attributes to get value validation back doesn't comfort me.

      If this is indeed because of CHECK, I'll be happy to add another module, one that does the same thing without attribute syntax1. Attribute syntax isn't needed, it's just very nice syntactic sugar that doesn't require a source filter. But for some reason, I do not think this is the real reason for you not to use this lvalue properties.

      I hope that you just object to tie, or to anything that disagrees with perldoc, or to "experimental" features, because Perl 6 will assume you want lvalue accessors.

      I really like Ruby's compromise.

      So do I.

      However in Perl I'll continue to use rvalue accessors, thankyouverymuch.

      Don't let my advocacy for laziness stop you.

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

      (Update) 1 Of course, the lvalue attribute is still needed. I'm assuming, but not entirely sure, that they're not handled at CHECK time.
[reply]
[d/l]
        Funny. I thought that I just said that Attribute::Property is an unacceptable solution to me. That means that it doesn't take away the issue.

        But you're right that validation is not the only thing that I object to about lvalue accessors. With OO I'd expect to be able to do something like create a Length module, Length objects can be accessed/set in various units (inches, meters, feet, miles, etc). An external user should have no idea what the internal representation is.

        How do I do it with lvalues?

        I guess that you can use tie, but implementing that takes enough work and adds enough surprise that I don't see it as a net win.

        To me the syntactic sugar is simply not worth the extra work and complexity.

        As for Perl 6, I'll evaluate each feature and come up with my own opinions. I'll feel free to ignore anything that I don't like - the language is rich enough that I have no shortage of viable choices for which subset of features to use and which to ignore. If I don't like the implementation of lvalue subroutines there, I'll ignore it like I what Perl 5 does. If I like it, then I'll feel free to use it like I would in Ruby.

        And whichever I do, I'll feel free to dislike people who categorically declare that my considered set of choices are flawed.

[reply]

In Section Meditations