Piers Cawley wrote:
> > Users of the class includes people subclassing the class, so to them
> > they need to be able to use $.month_0 and $.month, even though there
> > is no "has $.month_0" declared in the Class implementation, only
> > "has $.month".
We thought about defining the attribute variables that way,
but decided that it would be clearer if they only ever refer to
real attributes declared in the current class.
Clearer in what way?
This implies that you cannot;
[
- refactor classes into class heirarchies without performing
code review of all methods in the class and included roles.
,
>> - "wrap" internal attribute access of a superclass in a subclass
].map:{$_ ~
That's why it's generally a bad idea to use the C<$.whatever> forms outside
your basic accessor methods.
}
This in turn implies that the $.foo syntax is, in general, bad
practice!
Yup.
Not very huffmanised, is it?
Making $.foo =:= $?SELF.foo, and getting to the "raw" attribute $.SUPER::foo
seems like the better solution to me. But of course, it would, because that's
how *I* program, and $?SELF != all(@coders).
Then we could even sneak in making $.foo(bar) a not-so-offensive ./foo(bar),
with ($.foo)(bar) meaning what $.foo(bar) currently means. But that really
is a seperate issue, and speculation of it meaningless if we retain the
current specified behaviour.
Sam.
