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

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

Thread Previous | Thread Next
From:
Johnson, Roy
Date:
October 17, 2003 07:30
Subject:
RE: RFC: changing behavior of defined() and exists()
Message ID:
162CD748CF8119438D558F0A96BDC59125D240@prw2kt82.corp.ercot.com
Thanks for considering my proposal. There were a few issues raised that
I will address here, even though I understand that it's not going to be
implemented (at least not anytime soon).

> From: schwern@pobox.com
> Sent: Wednesday, October 08, 2003 8:01 PM
>
> This doesn't strike me as straightforward at all.  In fact, its rather
> hackish to have an expression behave so differently as an argument to
a
> function.

True, it elevates defined() to something between a function and a
pragma. In fact, it could be a pragma instead of a re-spec of defined(),
but it's so likely to be used for individual expressions, that that's
cumbersome. 
    use defined;
    $v = $a || b;
    no defined;

> Another disadvantage is it complicates defined() and exists() in a way
> that's fairly difficult to explain.  

It's not difficult to explain that within defined(), only undef is
considered false, and that Boolean operators behave accordingly.

Currently, there is no reason to write
    if (defined( $a || $b)) {...
because it is exactly the same as
    if ($a || $defined($b)) {...

The proposed behavior gives a DWIM sense to the former. 

Since there is currently almost no reason to have Boolean expressions
within defined(), the proposed behavior does not affect in any way the
customary use, which is what I took to be your meaning in saying it
complicated them. The only reason people will have to put Boolean ops in
a define() is to take advantage of the new behavior.

> Finally, this looks like it would be a bitch to implement.

That's likely. If the only practical use anyone can see for it is the //
niche, it is not worth doing. It was my hope that the prospect of having
a context without multiple false values would have some appeal. 

Incidentally, there was a slight error in my equivalences. defined()
still returns the definedness of the expression, rather than its value,
though in a void context, it's a non-issue.
    defined($v = a() || b())  ## === defined($v = a() // b())
                              ## not just $v = a() // b()

> From: merlyn@stonehenge.com (Randal L. Schwartz) 
> Date: 09 Oct 2003 10:54:31 -0700

> How far down would it reach?  Is it merely lexical, or is it dynamic?

It's lexical. Yikes, I can't think of a reason in the world to make it
dynamic. It's pretty pragma-like (though there's disagreement about
whether it's pragmatic :).

> From: Nicholas Clark <nick@ccl4.org> 
> Date: Thu, 9 Oct 2003 19:06:39 +0100

> This cannot go into 5.8.x, because it would break existing code.

If it were implemented as a pragma (or in concert with a pragma), it
could be entirely conflict-free.


Roy Johnson
Roy.Johnson@ercot.com
512-248-3052



Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About