: > >is => typing, inheritance, etc.
: > >has => composition, aggregation, etc.
: >
: > True, but those are basic OO concepts, which don't neatly apply to
: > property-lists (a very old Lisp concept that Perl6 is adopting).
Well, you can think of it like that, but I'm actually trying for some
happy medium, where properties are a cheap form of inheritance, or
perhaps delegation, much like David suggests below.
David Whipp writes:
: "is" does seem to imply an OO is-a relationship. So lets run
: with it!
:
: If $foo is an object of type INTEGER, then $foo.bit calls a
: method that compares the numeric value against 0 and returns
: 1 if not zero.
:
: If $foo is true, then its method $foo.bit is expected to return
: 1.
:
: In OO terms, when you override the behaviour of your methods, you
: are usually subclassing. So perhaps the declaration "$foo is true"
: should literally mean: "create an anonymous subclass derived from
: $foo's class that overrides its .bit method to return 1; change
: $foo's class to this new subclass" Multiple "is" declarations
: would simply stack up the subclasses.
Yes, I'm thinking of it more in terms of delegation, since we probably
wouldn't dup the vtables, but that's the general idea.
: If "true" is a class with a single method "sub .bit { return 1 }",
: then the subclass of $foo is creating by copying "true"'s methods.
: So "$foo is myClass" simply means that we subclass $foo with a
: clone of myClass. "constant" would be a class that overrides the
: assignment operator.
I had thought about this some. It's actually possible to do anonymous
subclassing, but to do it efficiently, we'd probably need to coalesce
vtables that are structurally type equivalent. (Obviously you
can't have name equivalence when the subtypes are anonymous, so that's
not really a problem.)
: On a slightly different note, I read that "my Dog $foo" doesn't
: call a ctor. I do hope that "my URL $name; ...; $name="www.foo.bar"
: does DWIM.
Depends on what you mean. And just because C<my Dog $foo> doesn't
call a constructor doesn't mean that C<my Dog $foo ("spot")> won't.
: p.s. I prefer to paint my bikeshed's true and false as .bool, not
: .bit. In the hardware world, the distinction is important because
: we often slip into negative logic.
So bool would perhaps be a synthetic property that has opposite polarity
from bit? I can see that, sort of. It's something like electrons being
negative, thank you Mr. Franklin.
Larry
