Larry Wall <[EMAIL PROTECTED]> writes:
> On Thu, Dec 11, 2003 at 04:18:19PM -0700, Luke Palmer wrote:
> : Larry Wall writes:
> : > Anyway, this all implies that use of a role as a method name defaults to
> : > returning whether the type in question matches the subtype.
Why? Why should it be a method? I would have though the smart
match operator would do the job better -- as well as be less painful
than the .does() method. Hey, given that it removes the ambiguities,
I would call it less painful than use of a role as a method name.
> : If that's the case, how do we attach out-of-band properties on objects
> : that don't expect them, but only some of them (as was the original
> : intent for properties, IIRC):
> :
> : my role onlyonced;
> : sub onlyonce($arg is rw) {
> : die "onlyonce called twice on the same value" if $arg.onlyonced;
> : $arg but= onlyonced;
> : }
> :
> : Either that doesn't work at all, because you get an "onlyonced not
> : found" error, or it works because onlyonced is a declared role. But
> : in the latter case I worry about namespace pollution.
>
> Okay, maybe I understand your worry now. Are you worried that
> every object implicitly has boolean methods corresponding to every
> class/role/property name in scope? I can see where that might
> cause some heartburn.
... and ditching those boolean methods might spare us those
heartburns. What do we need them for, anyway, if the smart match
operator tests for out-of-band properties?
my role onlyonced;
sub onlyonce($arg is rw) {
die "onlyonce called twice on the same value" if $arg~~onlyonced;
$arg but= onlyonced;
}
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?
Eirik
--
[EMAIL PROTECTED]
Just this .sig then
nothing more
