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).