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.

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.

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.