On Thu, Nov 27, 2003 at 12:02:30AM -0700, Luke Palmer wrote:
: Here's a series of questions/confirmation requests about how properties
: work (but specifically run-time properties, not traits):
:
: Use C<but> to assign a property to a I<value>:
:
: $a = $b but foo; # $a has property foo, $b does not
That is correct.
: Properties are just out-of-band methods:
I had been thinking of the value as an object of a singleton class
that has an extra method. In other words, properties would merely be
mixins. But that would imply that the property hides any real method
of the same name. On the other hand, it would be nice to be able to
promote an inert property to an active method. But I think that has
to be done on purpose, not by accidentally having a method of the same
name. So I suspect it needs to be an error to have a name collision
between a property and a method unless the method specifically says
that it's emulating a property. This will fit it more with Perl 6's
idea of how to compose classes, We won't be doing mixins--we'll be
doing something better. It resembles something in the literature
called "Traits", but we're generalizing that, and calling it "roles".
(Oh, apparently C# 2.0 is thinking along the same lines with its
"partial classes", though I haven't looked at those in detail.)
A role is like a chunk of class that can be incorporated into other
classes. It's a bit like mixins, but it's safer than mixins because
it detects name collisions at class composition time. There's also a
resemblence to generics, insofar as a role is at least parameterized on
its super class, since a given role can be incorporated into different
classes. (And if a role can be parameterized on one class, there's no
reason in principle it can't be parameterized on multiple classes.)
The basic underlying philosophy is that classes should not be used
both to create objects and to specify the scope of reusable code.
At least, they should not be forced to do both of those. So I think
Perl 6 will attempt to divorce those concerns.
Needless to say, Apocalypse 12 will talk a lot more about roles.
But let me just say that I'm currently thinking of a property as a
funny role composed into a singleton class. As a role composition,
we get control over any name collisions.
: if $x.foo { print "$x has property foo" }
: $x.bar = 1; # Or $x = $x but bar
Or maybe the .bar notation is only for rvalues, and to create a
property you have to say:
$x but= bar;
: Which makes meta-properties (eg. C<nothing>) easy to fathom.
That would certainly be easy to do under a role-playing implementation.
: (That one seems a little dangerous from an error checking point of view.
: Is there such thing as a 'method not found' error?)
Certainly, as long as we limit the .bar notation to rvalues or to
lvalues on already-created properties. And in fact, we may be limiting
the creation of properties to predeclared names, so that even
return 0 but ture;
can be caught at compile time.
: To get a hash of out-of-band properties, use either the C<btw> or the
: C<props> method, depending on whether our language designers are feeling
: cute.
The feeling of this language designer at this moment is that
properties aren't kept in a hash. They're indistiguishable from
other attributes/methods except insofar as they are composed into the
singleton class from roles that happen to be marked as property roles.
If we have a .props or .btw method of accessing that set of methods,
it's just syntactic sugar for ordinary method introspection with a
funny selection criterion.
Now it's certainly possible that non-active properties will be
optimized to a hash of non-active values internally, but we shouldn't
really think of them that way. We should think of them as methods
of a singleton class, or more precisely, of a role that cuts across
a number of singleton classes. In that respect it's a bit like
aspect-oriented programming, only it happens conceptually at compile
time, without having to write a bunch of method wrappers.
Larry
P.S. I think we deserve a $rubyometer-- for bypassing mixins.
