Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51848
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=wGE+dWY7YXqH0PzzWNw1qlNwJAO5hRh95ah/V0t/P8LVay6jqZi3G7URNWpzxR2bn4
         wFVVE0xO3XmZ4IkOoiO+8tcCseWBipNeYPrv3KiVnBptSQHA/Sq1Jf7Jmdd58/k+qIKu
         pss3tdwPyk8hOea3Nh8tkA/G2fB6ZMhSrLnkA=
MIME-Version: 1.0
In-Reply-To: <718216446.20110408143441@cypressintegrated.com>
References: <AANLkTiknomAsTrsZ140rWs6CwxJP3UYGUokQbERhDiRp@mail.gmail.com>
	<4D950434.3060704@yahoo.com.au>
	<BANLkTinzb5xiD8j7ZXB+cT4EBZY3DF6BYQ@mail.gmail.com>
	<4D9E0543.1080600@lerdorf.com>
	<69.82.36433.EC33E9D4@pb1.pair.com>
	<4D9E34C4.5000406@lerdorf.com>
	<4D9E429B.20503@sugarcrm.com>
	<4D9E96B6.6060401@lerdorf.com>
	<BANLkTi=LvYLaOoGgrzrWfYbQ+t9Wzv_XeQ@mail.gmail.com>
	<BANLkTim6ZBWw66rzx_gSvWc9E45EZx2_gw@mail.gmail.com>
	<BANLkTinxG6FtOqa8KzmvgTT1EFfM-6prow@mail.gmail.com>
	<BANLkTinsnqGSVTz=XPhCfX95mfeJ_pkhCg@mail.gmail.com>
	<BANLkTi=nwij4sfkKnNdM_NP9w2CArK6NHQ@mail.gmail.com>
	<BANLkTikghRix9VbpHDx+rnCRtnjdjeshmg@mail.gmail.com>
	<718216446.20110408143441@cypressintegrated.com>
Date: Sat, 9 Apr 2011 14:16:52 +0200
Message-ID: <BANLkTimW12_1jjc9-AdGy2qh=1p9RGcpwQ@mail.gmail.com>
To: Sanford Whiteman <swhitemanlistens-software@cypressintegrated.com>
Cc: Matt Pelmear <mjpelmear@gmail.com>, internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
From: rumi.kg@gmail.com (Rune Kaagaard)

Hi guys

Below is a discussion about some of the issues being raised. Again a
nicely formatted version of the whole thing is here:
https://gist.github.com/909711.

## Discussion ##

### About changing the beviour of the ternary shortcut ###

@Jordi, others

Some suggest adding an implicit `isset` around the value being tested in the
ternary shortcut. This I think is less than optimal because:

1. It would be a huge BC break, because a boolean test and a isset test differs
   greatly. [3]
2. It would be a major WTF, because it would work different than the normal
   ternary operator that it is a shortcut of.

Jordi suggests adding an implicit `!empty` around the value being tested in the
ternary shortcut. This would not break BC but it still wouldn't improve usecases
where the value tested for is allowed to be falsy ('', 0, "0", false, etc.):

    function render_articles($rows, $settings) {
        // Shows the last page per default. Zero based.
        $settings['page_num'] = $settings['page_num'] ?: count($rows) - 1;
        // ...
    }

    // Lets render_articles showing the first page.
    echo render_articles ($rows, array('page_num' => 0));

The obvious bug here is that since 0 is considered falsy, render_articles
will show the last page instead of the first. The correct version is back in
non-dry mode:

    $settings['page_num'] = isset($settings['page_num'])
        ? $settings['page_num']
        : count($rows) - 1;

Im writing the same stuff three times. With the `??` operator it would be:

    $settings['page_num'] ??= count($rows) - 1;

### Why we need both an Isset and IsNotEmpty operator ###

@Hannes, Ben

What's considered falsy in PHP is _very_ dynamic. Depending on context the
following can easily be considered falsy:

    '', null, undefined, array(), false, 0

Therefore we need to be very precise when we are making decisions based on a
variable or statements value. This is where `isset` and `!empty` compliments
each other very well. Sometimes i want to use a default value when falsy means
"this variable is not defined". Other times I want to assign a default value
when falsy means "this variable is not an empty string".

Sometimes the behaviour we want will change while we are working on the code.
Therefore I strongly believe that not having both operators would severely break
the symmetry and force the end user to make tedious and non-dry refactorings
just because he needs a function to - under certain conditions -
return false or
vice versa.

## References ##
    * [3]: http://php.net/manual/en/types.comparisons.php