On Sun, Jun 05, 2005 at 10:22:16PM +0200, Ingo Blechschmidt wrote:
: Hi,
:
: two quick questions:
:
:
: Are multi submethods allowed?
Presumably.
: my $x = undef;
: my $y = $x.some_method;
: # $y now contains an unthrown exception object, saying that undef
: # doesn't .can("some_method"), right?
: say $y; # Only now it dies, correct?
:
: This is important if you have a sub which may either return a custom
: object or undef:
: my $x = sub_which_returns_an_object_or_undef();
: my $y = $x.some_method;
:
: One builtin example is "caller":
: my $x = caller(5555); # undef if there's no such stack frame
: my $y = $x.line; # unthrown exception object
That's an interesting question. Perl 5 tends to throw an exception
as soon as you try to call an undefined method, but we also have the
problem of accidental autovification in multidimensional rvalues that
we'd like to avoid in Perl 6, and so we'd kind like it if undef.[1]
didn't try to autovivify in whatever container contains the undefined
entry unless the whole thing is in lvalue context. My general feeling
is that we shouldn't extend that to all methods, though, but perhaps
only to methods that have declared they can be transitively undefined
somehow, much like we're differentiating operators that know they
have an identity value from ones that don't. I'm just a little leary
of making exception throwing completely lazy everywhere unless there's
some pragma to that effect. I'm not sure consistency is the best
policy here. It feels more like one of those early- vs late-binding
knobs we should let the programmer twiddle.
Larry
