in reply to Assignable Subroutines

It strikes me that the thing that prevents validation of values assigned to lvalue subs, is the way in which the lvalue is determined--by being the last line/value of the sub.

If there were a keyword that allowed the programmer to indicate what the lvalue was, he could choose where in the sub that lvalue was positioned and control could be returned to the sub after the assignment has taken place. 

sub thing {
    my( @args ) = @_;
    
    ... code to determine what the lvalue should be.
    
    LVALUE{ $lvalue };
    
    if( $lvalue eq some condition ) {
        ... take positive action;
    }
    else {
        ... take negative action;
    }
}

[download]

In use, the interpreter would run the code until the (or a?) LVALUE statement is encountered. This is directly equivalent to the current situation of running the sub to determine the lvalue. Once obtained, the LVALUE would be available to the calling code to use in whatever manner. Once the statement that called the sub completes, the remainder of the sub would be run, with the assigned value in place for veryification or whatever else the programmer might wish to do to it.

There are probably a gazillion reasons why this won't work, but it seems to address most of the issues raised, whilst providing for inline, intuative validation.

The main advantage I see of this over tieing, is that the validation code is at the same scope as the the lvalue determination code.

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

Replies are listed 'Best First'.
Re^2: Assignable Subroutines
by Aristotle (Chancellor) on Jan 26, 2005 at 02:33 UTC

    Btw, such a mechanism exists. You're basically saying that lvalue subs could be implemented as coroutines which are expected to yield the lvalue.

    That's an interesting way of looking at this.

    Makeshifts last the longest.

[reply]
      ...implemented as coroutines which are expected to yield the lvalue.

      Not really. I may appear that way, but coroutines flip back and forth. This doesn't.

      In actuality, there would be very little difference between this and using a tie/STORE method to validate.

      • The method is called to obtain the lvalue which is returned to the calling code.
      • At some point the calling code makes an assignment to the lvalue and (because that lvalue is tied) the STORE method is called.

      Except in this case the "STORE method" is the code inline from the LVALUE statement to the end of method.

      One distinct difference between this and a tie/STORE method, is that if the lvalue in question is an array or a slice of an array, the "callback code" would only be called once. Not once for every value in the list being assigned.

      I am still unsure what happens in the calling code if the STORE method (disguised or not) rejects the attempt to store a value?

      I also thought about whether the PRE/POST or ENTER/LEAVE blocks associable with a method could be used to provide for a single place in which all validation is done, but my reading of the Apos & Syns leaves me very confused about when these get called, if ever, with an lvalue sub.

      Of course, this whole discussion is a waste of time. Who are we to question whether there is a better way? Explain to plebians. Pah!

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

        I may appear that way, but coroutines flip back and forth.

        You don't appear that way, don't worry. ;-) Well, this feature could still be implemented with a coroutine.

        In any case, now I see what you were saying. There is indeed effectively no difference between your proposition and tieing. So why invent a new special-use mechanism rather than streamlining an existing one that can do the same job and more besides?

        Who are we to question whether there is a better way? Explain to plebians. Pah!

        Well, he did say:

        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.

        And I agree with him. Just because we're used to putting validation in accessors doesn't mean it's the best way to do things. But all the discussion we've been having about lvalue subs revolves around trying to ease doing validation the way we've always done it, whether or not that's the best way to handle it. I've said before that I don't think it is.

        Makeshifts last the longest.

[reply]

In Section Meditations