Re^2: Use method/function signatures with Perl

[tilly]

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.

[Juerd]

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
    }
}

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 syntax¹. 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.

(Update) ¹ Of course, the lvalue attribute is still needed. I'm assuming, but not entirely sure, that they're not handled at CHECK time.

[tilly]

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.

[Juerd]

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.

I'm not disagreeing about that. You said that I indicated something; I cannot recall having indicated that exact thing, and tried to correct.

Let's not make a big deal out of everything. Feel offended if you wish, but please only do so knowing that I didn't mean "flawed" as an absolute condemnation and that no offense was intended. I like Perl for its tolerance towards almost all programming styles, but that doesn't mean I steer clear of discussion.

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?

In that rather specific case I would not use lvalues, or any setter method, for that matter. I'd be inclined to think of these values as immutable objects, and have something like:

package Length;

sub new {
    my ($class, $value, $unit) = @_;
    # Create $self and store the value in standard form. 
    # In case of length this means converting the length to meters.
}

sub as_km  { shift->{_m} / 1000 }
sub as_hm  { shift->{_m} / 100 }
sub as_dam { shift->{_m} / 10 }
sub as_m   { shift->{_m} }
sub as_dm  { shift->{_m} * 10 }
sub as_cm  { shift->{_m} * 100 }
sub as_mm  { shift->{_m} * 1000 }

# Or, if this were really something I made, just:
sub as {
    my ($self, $unit) = @_;
    # ...
}

But instead of using Length objects, I am much more likely to dictate that every length must be stored in meters, as a number. Possibly with the addition of utility functions to aid in conversion.

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

I'm sorry you make this about people. I wonder, though, how you survive PM if you take offense every time someone disagrees with you on a technical subject. You are of course free to dislike me, or any person. Even though we will probably never meet in person, I regret that you dislike *me* instead of only what I said.