HaloO,
Stuart Cook wrote:
On the other hand, there are other things that don't work quite so well:
my Dog $spot;
$spot.can('bark'); # Not until he's instantiated...
Are you objecting to the fact that it can't possibly return a valid
method, or that it will inappropriately true/false (depending on your
point of view)?
Might I add my view of affairs? I want to point out the difference
between a slot call and a free method here. Major difference is that
a slot call starts from the $spot sigil expression, determines the
class and looks up .can there and calls it. While a free method .can
is lookup up first in namespace and then $spot has to qualify as an
invocant type. The selected dispatch target has to accept a Str
parameter and is executed in Void context.
Yeah, but if we're trying to view (undef but Dog) as the platonic
instance of Dog,
$Larry very nicely said that the name Dog here represents all
the potentialities with the package/module/class behind it.
I regard this potentiality as type information. That is after
my Dog $spot; the type of $spot is 'Item of Undef of Dog'.
it would be nice if told us what the ideal Dog can &
can't do. (In either case, the metaclass will be able to tell us.)
Something to ponder, I suppose.
Proposal: could we call all this META stuff somewhat generically
"Meta Info"? I mean .meta delivers a thingy that .does(Meta) nothing
more nothing less. There are whatever methods defined on that type.
Does that help you pondering?
In more implementation oriented terms .meta returns an opaque pointer
from which other methods can deliver whatever stringy, objectish or
classish information, links or refs. I guess parts of the structures
that this opaque pointer points to are really located on the Parrot
C level or equivalent things in other interpreters supporting Perl6.
--
$TSa.greeting := "HaloO"; # mind the echo!
