in reply to Re^16: Assignable Subroutines
in thread Assignable Subroutines

It is a P5 simulation, without the benefit of P6 lexical subroutines. How do you think this will work? 

class ....{
    my sub thingie1 is rw {
        return my $var
            is Proxy( for => $hidden_var,
                      FETCH => { ... },
                      STORE => { ... },
                      TEMP  => { ... },
                      ...
            );
    }
    my sub thingie2 is rw {
        return my $var
            is Proxy( for => $hidden_var,
                      FETCH => { ... },
                      STORE => { ... },
                      TEMP  => { ... },
                      ...
            );
    }
    ...
}

[download]

And, if the ties involved in the my suggestion above, are generated by the compiler, what is to stop them from using the same mechanism as this Apo6 code uses to isolate the tie for one attribute from the tie for another?

The only difference is who writes the code and where. One is inline, clear and trivial with the compiler doing all the drudge work.

The other is, out-of-band, complex, obscure and repetative, requiring the programmer to code lots of little code blocks instead of a simple, inline block of code.

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

Replies are listed 'Best First'.
Re^18: Assignable Subroutines
by Aristotle (Chancellor) on Jan 27, 2005 at 19:16 UTC

    I'd imagine something closer to

    return my $var but :setter { ... };

    [download]

    where $var is probably accessible in the setter as the current topic.

    Makeshifts last the longest.

[reply]
[d/l]

      Okay. I am far from wedded to the LVALUE, or the form of the syntax. (Not that I think :setter is much better:).

      I have distinct reservations about the 'but' keyword. It sounds too much like an afterthought--barely worth worrying about-to me.

      But (sic) a single code block, coded at the point of use, with whatever else is required to make that work being taken care of by the compiler. That I could live with, whatever the syntax.

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

        I have distinct reservations about the 'but' keyword.

        Talk to Larry about that. I'm using established Perl6 syntax. And I don't share your opinion about the alleged implications; particularly not because this is the Perl6 “but”, not the English “but”.

        You repeatedly mentioned having read the Apocalypses and having followed Perl6 development for a while; I expected you'd know that this sort of thing would be enabled by Perl6. But you kept railing against how Perl6 is going to handle it.

        As far as having setter code inline or keeping it externally in a class or some such like, I believe both are necessary. There are many cases where type-based validation will suffice (the vast majority, judging by the kind of validation I predominantly write in my code), and I don't want to have repetition for that. There are some cases where I'll want to validate on state, and being able to use inline code would be beneficial with those. I never argued against the latter; I just kept trying to show you that the former is quite desirable as well. The type system won't be the only way to validate in Perl6; notice Larry said “most such cases” would be handled by the type system in Perl6, not all.

        So we've really been more in agreement than not for most of the duration of this argument…

        Makeshifts last the longest.

[reply]

In Section Meditations