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

Then, with respect, I think that you and I are reading different threads.

And that maybe you have missed all the discussion around the use of lvalue subs for accessors and mutators over the past 2 1/2 years. Literally every time the subject has come up, their use has been nearly universally rejected because of the absence of the ability to validate the assignment, without the resort to hookey, repetative and slow tieing of the underlying lvalue that is assigned. Every time.

Even with the slightly streamlines syntax outlined in Apo6, it is still forcing the programmer to code additional and complicated code for every attribute of every class. Extra work in what will be the common case for--as best as I can tell--the purpose of avoiding it in the particular and less common case.

For me, that renders the one feature of P6 that, aboe all others, I was looking forward to, almost useless. Better to stick with the current: 

sub getset {
    my self = shift;
    return $self->{thing} unless @_;
    die "Bad value" unless $_[0] =~ /valid/;
    $self->{thing} = $_[0];
}

[download]

It's easier to code. Easier to read. Easier to debug. And probably quicker.

I'll refrain from passing further comments on P6 related matters, because I think I just joined that band of people who will probably never use P6.

Examine what is said, not who speaks.
Silence betokens consent.
Love the truth but pardon error.

Replies are listed 'Best First'.
Re^7: Experimenting with Lvalue Subs
by Aristotle (Chancellor) on Jan 25, 2005 at 04:10 UTC

    What prevents you from writing, say, a Tie::IntRange class that constrains the values assigned to the scalar it ties, and reusing that code 1,500× for all your 1,500 attributes (with a different range declared in each instantiation of the tied class)? Or Tie::EnsureMatch which constrains the values assigned to the scalar it ties to those matching a particular regex supplied at instantiation time?

    This kind of reuse is really no different from what we already use Params::Validate for in another context.

    Makeshifts last the longest.

[reply]
      You're on the right track. Attaching validation routines as setters is falling into a kind of cut-and-paste fallacy. Most such validation should really be done by the subtype system in Perl 6. Merely declaring your attribute to be of the proper subtype will prevent bad values from being assigned to it. The subtype is usually the proper place to attach your validation sub, not the attribute setter.

      Anyway, I'm kind of sick of this thread. People are getting exactly the same kind of tunnel vision they had when they wrote the RFCs in the first place, and not seeing how the Perl 6 feature set works together as a whole. They don't see how syntax mutability and dispatch rules will let them cargo cult in whatever silly syntax they like; they'd rather screw around with the clean underlying semantics instead.

      Gee, let's just recapitulate the whole RFC process here on PM. Maybe it's about time to trot out highlander variables again. Multiline comments anyone? Ooh, let's make my the implicit default. And I've got this great idea for the colon character... :-)

[reply]
[d/l]
[select]
[reply]

In Section Meditations