# lvalue methods

I recently attempted to write a sample mutable role that made use of a
number of lvalue methods, and I had a bear of a time getting it to
work.  Could we arrange for a more intuitive option to be available?
For example, allow the programmer to pass a writer code block in
through the rw trait, and assume that the default codeblock is a

method x() is rw( { \$.x = \$_ } ) { return \$.x }

The idea is that if this is being called as an rvalue, the { return .x
} block would be called, but if it's being called as an lvalue, the {
.x = \$_ } block would be called.

The above example is of course trivial.  A more serious example might
be one based off of a coordinate system:

role point {
has Num \$x, Num \$y;
method angle() is rw( { \$.x = .r * cos(\$_); \$.y = .r * sin(\$_)
} ) { return atn(\$.y/\$.x) }
method r() is rw( { \$.x = \$_ * cos(.angle); \$.y = \$_ *
sin(.angle) } ) { return sqrt(\$.x * \$.x + \$.y * \$.y ) }
}

This strikes me as being much more readable than the current approach
of explicitly returning a proxy object.  I'd even be fine if the above
were treated as syntactic sugar for the creation of a proxy object -
that is, have:

method x() is rw( { \$.x = \$_ } ) { return \$.x }

be exactly equivalent to something like:

method x(\$val) is rw { return new Proxy:
FETCH => method { return \$.x },
STORE => method { \$.x = \$_ }
}

...but without the programmer having to worry about how to access the
role's attributes from within the proxy object.

--
Jonathan "Dataweaver" Lang