Mention is made of a typed undef in A12:
<A12>
which doesn't quite work, because $spot is undefined. What probably happens
is that the my cheats and puts a version of undef in there that knows it
should dispatch to the Dog class if you call .self:new() on it. Anyway,
we'll make it work one way or another, so that it becomes the equivalent of:
</A12>
I want to point out this is a pretty good idea overall, not as just some
"magic" behavior. Specifically, if I say:
my Dog $spot;
I should then be able to call class methods of Dog via $spot without further
initialization:
print defined($spot); # FALSE
$rover = $spot.new;
@breeds = $spot.list_breeds;
This is, as pointed out, just sugar for Dog::new and Dog::list_breeds, but
it brings up the spectre of undef invocants:
class C {
method ctor {...}
method foo returns C {...; return undef; ...}
method bar returns C {...; return undef; ...}
method baz {...}
}
my C $c .= ctor; # $c is defined and all is well.
$c->foo->bar->baz; # If foo or bar fails, what happens?
There are potentially two flavors of undef:
undef
undef but class = C
Given that the foo and bar methods are declared to return C, should the
'return undef' code emit a 'pure' undef, or a undef-of-type-C?
And if so, should it be legal to have an undef invocant? A typed-undef
invocant?
This sort of wanders towards the question: Is undef a value, or a
meta-value? That is, can a UDT rely on scalar undef as part of its range (a
la NaN/Inf in the numbers space) or must undef be considered part of the
Perl domain, "you're not a Thingy yet."
(The mapping of undef <-> SQL's NULL comes to mind.)
=Austin
