On 4/19/04 3:58 PM, Austin Hastings wrote:
>> I initially decide to accept the default accessors.
>>
>> $dog.name = 'Ralph';
>> print $dog.age;
>>
>> This works well for a while, but then I decide to update Dog so that setting
>> the name also sets the gender.
>>
>> $dog.name = 'Susie'; # also sets $dog.gender to 'female'
>>
>> How do I write such a name() method?
>
> has $.name is rw
> will STORE { .set_name($^name); };
The "will STORE" stuff covers the easy cases, but can I extend it all the
way up to a name() that's a multimethod with a ton of optional args? I
supposed you can (technically) do all of that with "will STORE", but it
seems an odd place for what would more naturally be code in the name()
method itself.
> You can leave the "name" attribute around as a placeholder and let the STORE
> block update the "official" location, or you could return some sort of
> proxy-lvalue object that wasn't really a part of Dog
Heh, getting progressively more scary :)
>From the point of view of the person coding the new, fancier name() method,
it would be nice if some magic would make all existing calls to
$dog.name = 'foo';
look like this inside the new name() method
$dog.name('foo');
but I supposed that really hoses the meaning of "=" :)
The alternate techniques suggested are powerful, but they also strike me as
slightly heroic. I can imaging using them to patch or extend some existing
code, but starting a Perl 6 class from scratch, I'd really have to think
about the costs of using the default accessors at all.
One work-around might be an alternate kind of default accessor that doesn't
allow assignment:
$dog.name # get
$dog.name('foo') # set
$dog.name = 'foo' # compile-time error
That is a lot more directly (and simply) "future-proof" than the "is rw"
accessor.
I'd either like a way to more cleanly extend the default accessor's
assignment behavior down the road (i.e. by just writing a new name() method,
not by hacking away at STORE traits and adding private worker subs) or a way
to auto-generate the slightly more "boring" default accessor shown above.
I'd prefer the former since I'm hoping to avoid the likes of
Class::MethodMaker as long as possible in the world of Perl 6 :)
In the absence of both, I can imaging that 5 years into the life of 6PAN, a
substantial portion of the Perl 6 modules will have STORE hooks on what they
originally thought would be "simple" attributes that don't need full-blown
accessors... :)
-John
