Larry Wall <[EMAIL PROTECTED]> writes:
> On Fri, Dec 12, 2003 at 04:05:25PM +0100, Eirik Berg Hanssen wrote:
> : I for one would appreciate the visual clue that we access properties
> : and subclasses as roles ($foo~~bareword), while we access attributes
> : (with accessors) as methods ($foo.bareword). Different things should
> : look different, right?
>
> I still think that you can access the role itself as a method, but only
> if it's really there. In that case the different thing is trying to be
> the same. A simple property should behave like an attribute when it can.
When I wrote that, I still had in mind the "boolean methods
corresponding to every class/role/property name in scope" -- but I
think you mean something else when you speak of accessing the role.
Specifically, I think you mean what I would call "accessing the role's
(main) attribute". If so, we are still in agreement. If not, I am
very much confused. :-)
Red and Reddish (per your example) are not properties, given your
definition in the other thread. So you are not arguing for Red and
Reddish to be accessible as methods, I gather.
I can see this, I suppose:
$bar but= $foo.Color if $foo ~~ Color;
if $bar ~~ Reddish {
print $bar.hex_code; # hex_code is a method of the role,
# and so can be accessed directly.
$bar.Color.red = 0; # red is not a method of the role,
# and must be accessed through the
# role's main attribute (for which
# red is an lvalue method, it seems).
}
But this would all come about because the role defines an attribute
by the same name, not because method lookup scans the role namespace.
Or so I would hope.
And then it is no different from being able to access as a method
any public attribute (or other method) that the role defines -- if the
role is really there.
Or am I very much confused?
Eirik
--
Rudolph is at _least_ as real as a Cantor set or an untried recipe.
-- Joshua W. Burton <[EMAIL PROTECTED]>
(<[EMAIL PROTECTED]>)
