On Wed, 2002-05-15 at 13:02, Larry Wall wrote:
> Aaron Sherman writes:
> : Should a tied and/or lazy array be forced to present a length on demand,
> : or can length return undef on indeterminate arrays?
>
> An array implementation can return anything it jolly well pleases, but
> I'd say undef would be a reasonable thing to return if the length is
> indeterminate. Then you can at least get warnings if you try to use
> the undefined value later. The class could even tag the undef with a
> property containing an unthrown exception that explains why the length
> is indeterminate, since Perl 6 will support interesting values of
> undef.
I had to give this one a day... First off, I'm sick so I wasn't really
thinking clearly enough to respond yesterday. But more importantly, I
learned more from this one post about how you see things working in
Perl6 than from most of the Apocalypses.
So, you see something like:
method length() {
if (...we think we know...) {
return .len; # See discussion on inlining accessors
} else {
return undef but exception("Homer::Doh: no known length");
}
}
[...]
$foolen = @foo.length // die("$0: Why, oh why: $!");
Interesting. Even more so because applications that don't take the time
to check @foo.length's return value for definedness will go on assuming
it has no elements, which is probably a good fall-back for code that
isn't paying enough attention (and of course, there's the warning).
