> -----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