[EMAIL PROTECTED] writes:
: I guess a good rule would be, "Use return values consistently. If you
: have to return data, then use the true property to return status. If
: you can't use :true, then use :result."
By and large, it's best if the data itself is properly oriented so that
there's little need for a "true" property. Most of the time, true
values are more interesting than false values, so it generally works
out that way. The main exceptions are, er, exceptions.
So I don't actually see the "true" property being used all that much,
except in the places you currently would see "0 but true". I think the
status will generally be returned as the actual argument, and extra
info attached as a property:
return undef is error("Gorkulator borked");
That is, it's returning the exception that it *would* have thrown if
use Fatal (or whatever) had been in effect.
Now the really interesting thing is that, further on in the program, we
now know not only that the value is undefined, but we know *why* it's
undefined, and we could add that into any warnings about the use of
the undefined value, or perhaps transmogrify such a warning into a
fatal at that point.
Now that's action at a distance, but of a more delightful kind.
: my $fh = open(fname) or die "Argh!"; # uses :true
That's not how I see it. The filehandle is naturally true if it
succeeds. It's the undef value that wants to have more information.
In fact, you could view $! as a poor-man's way of extracting the error
that was attached to the last undef.
An object like $fh should define its bool method to be true as long
as it's a valid way to represent whatever it is that it's trying to
represent. (Or equivalently, the object should inherit such a method.)
Larry
