develooper Front page | perl.perl5.porters | Postings from October 2003

Re: RFC: changing behavior of defined() and exists()

Thread Previous | Thread Next
Nicholas Clark
October 9, 2003 11:08
Re: RFC: changing behavior of defined() and exists()
Message ID:
On Wed, Oct 08, 2003 at 03:47:35PM -0500, Johnson, Roy wrote:

> I was reviewing the age-old debate on the // operator, and saw the
> various, often clunky, proposals for avoiding it. I never saw this one,
> though, and it struck me as being elegant:
> defined() should evaluate its arguments in a context [I'm using this
> term generically] wherein only undef is false. The normal usage of
> defined() is unchanged: if you give it an undef value, it returns false,
> otherwise, it returns true. However, if you give it a complex Boolean
> argument, all of the logical operators recognize undef as false, and
> everything else as true, and logical operators yield undef instead of
> normal-perl-false.

This cannot go into 5.8.x, because it would break existing code.
5.10 will have the defined or operator. Hence this change would buy
nothing for the first two examples you suggest.

> Examples:
>     defined($v = a() || b())   ## equivalent to $v = a() // b();
>     defined($v ||= a())        ## equivalent to $v //= a();
>     defined($v = \( $a && $b && $c && 'full'))
> The last one makes $v a reference to the first undefined value in the
> list, or to the constant 'full' if all of them have been defined.
> defined() itself will return the appropriate truth value for its
> context.

I can't see an easy way that // would let you emulate that, but I'm
not convinced that that sort of construction is that common

> Advantages:
> No new keywords or operators are required for this behavior. It is
> straightforward and provides access to all logical operations, rather
> than being specific to two. It expands the universe of expressions for
> which the existing functions are useful.
> Disadvantages:
> It still does not make it easier to do something like:
>     $a = a() // b() || c() // d();
>   which would be (as it currently is):
>     defined($a = a()) || ($a = b()) || defined($a = c()) || ($a = d());
> "defined" is still a relatively long word

Given that it cannot go into 5.8.x because it would break existing code,
and hence it could only go into a perl that already has //, the advantages
seem much smaller.

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About