On Fri, Dec 12, 2003 at 04:05:25PM +0100, Eirik Berg Hanssen wrote:
: 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.
Having slept on it overnight, I've come to the same conclusion.
: > : 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?
And also, smart match is the right place to put dwimmery, not method lookup.
: 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?
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.
Larry
