> -----Original Message-----
> From: Mark J. Reed [mailto:[EMAIL PROTECTED]
>
> Let me just chime in with my support for John's basic idea. I would
> definitely prefer that it be easy to arrange things such that
>
> $obj.foo = 'bar'
>
> winds up invoking a method on $obj with 'bar' as an argument, rather
> than invoking a method on $obj that returns an lvalue to which
> 'bar' is then assigned. (Yes, like Ruby's def foo=; I have a Rubyometer
> and I'm not afraid to use it!) It doesn't need to be the default
> rw accessor behavior, but I would like it to be accomplishable without
> jumping through a lot of hoops.
A problem with
$obj.foo = 'bar';
getting converted to
$obj.set_foo('bar');
(or whatever) is that set_foo may not have lvalue semantics. That is, it may
not behave appropriately by returning an lvalue object for use in cascading
assignment constructs:
$obj.foo = $obj.baz = 'bar';
Hanging the behavior off C<will STORE> and/or C<will FETCH> has the benefit
of P6 doing some or all of the work for you.
has $.foo will STORE { .:set_foo($^value); }
submethod :set_foo($new_foo) {...}
...
$obj.foo = 'bar';
A better solution to your scenario is to 6PAN a new MetaClass that does what
you want:
use AccessorClasses;
accessor_class Object
{
has $.foo is rw;
method :set_foo($new_foo, ?$optional_extra) {...}
method :get_foo() {...}
}
A simple, easily bundled grammar mod that automatically generates the C<will
STORE> logic for you, provided that you follow a simple xxx_ method naming
convention.
=Austin
