Graham Barr <[EMAIL PROTECTED]> writes:
> On Fri, May 18, 2001 at 08:31:21AM -0500, Jarkko Hietaniemi wrote:
> > On Fri, May 18, 2001 at 06:22:10AM -0700, Austin Hastings wrote:
> > >
> > > --- Damian Conway <[EMAIL PROTECTED]> wrote:
> > >
> > > > It's probably just a matter of coding what you actually mean.
> > > > In Perl 5 and 6 your version means "if $fh is true in *any*
> > > > possible way...", whereas you seem to want "if $fh is defined",
> > > > which is:
> > >
> > > Hmm. I can easily see this producing incomprehensible code when spread
> > > across large systems. To wit, those developers used to "0 means false"
> >
> > Any feature is incomprehensible if one is not used to it. Pointers
> > in C are incomprehensible if one has never met the concept before.
>
> Right, consider overloading.
>
> > As far as I understand one rationale behind the "false (in Perl 5 terms)
> > but true (in Perl 6 terms)" is that you can write code like this
> >
> > if ($retval = func(@args)) {
> > # it worked ...
>
> Right. Which of course can be done in Perl 5 with either "0 but
> true" (or "0E0") or if the value is an object, the use of
> overloading.
But what you can't do with 0E0 is the else branch of that example,
accessing C<$retval.what_went_wrong>, which would be really handy...
--
Piers Cawley
www.iterative-software.com
