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. That is,
: > when you say
: >
: > $foo.true
: >
: > it's asking whether the Boolean property fulfills the true constraint.
: > When you say
: >
: > $bar.red
:
: So are you saying that, eg.
:
: class Something does Color {...}
: my Something $flib;
:
: if $flib.red { print "Flib is red" }
: if $flib.true { print "Should be an error before now" }
:
: Since Something doesn't Boolean, true would be a "method not found"
: error?
Well, true is perhaps a bad example, since everything is boolean one
way or another. Built-in types inherit a true method that depends on the
actual value, not on a property.
: 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;
That might need to be "my property" to get everything defaulted for
a property kind of role. But maybe not.
: 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.
I think it works because it's declared, and because you're using it
in a boolean context, so it's not really testing the value of the
property, but it's presence. The .onlyonced method merely tests
whether the object "does" onlyonced.
: But in the latter case I worry about namespace pollution.
Which namespace are you worried about polluting? It seems to me that
restricting the name to a lexical namespace and to the current object is
about as good as you can get. We're not polluting the class's namespace,
nor are we polluting the global namespace. (Though there are times where
that's the right thing to do.)
Or are you thinking that you might want to apply a property more than
once to the same object? (That would make about as much sense as
inheriting more than once directly from the same base class.)
Or are you worried that these have to be declared at all? I think we
need to declare them or we can't use them as bare identifiers. There
are no barewords in Perl 6, so they have to be something predeclared,
or otherwise syntactically distinguished. We could syntactically
distinguish them in the presence of C<but>, but that doesn't let us
use them anywhere else, and it makes C<but> into more of a macro than
an operator, which seems unclean. Letting them be bare identifiers
under the predeclared classname rule seems to be the most appropriate
way to do it, if indeed properties can be unified with roles (and
roles with classes). And I suspect they can be unified, and ought
to be unified. My goal isn't so much to make sticky notes as hard to
use as subtypes, but to make subtypes as easy to use as sticky notes.
I think it ought to be easy for any object to pretend to be some other
kind of object. Allomorphism is not just for untyped Perl scalars.
That being said, there has to be a little discipline to it, or we'll
find ourselves in property hell. I think roles provide a nice level
of discipline.
: It's clear that I don't entirely understand all of this yet (er, as much
: as there is to understand... yet).
Well, I don't entirely understand either. One thing I do understand
is that people get scared when I start thinking out loud. :-)
Larry
