<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