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.

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

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

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

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.