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
reader codeblock. Something like:
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
