Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51892
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain yahoo.com.au from 98.139.52.211 cause and error)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com.au;
  h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
  b=VYCzxNtgtRp0nMWS80PdplLdZHk/v1XQ5p8zm9PasvL1ifXrhMHlA42OGxTPf6pP2LPabJzYSLxhDbjoGOn5dLIPEpGzpZd6wvASgY5J4OdKf2WQYa7nWesjHb+0/N7QFfJ2diCnhkBXyNLid4od8Qr7khWySGTO3j7LjlYdnws=  ;
Message-ID: <4DA6E151.4030707@yahoo.com.au>
Date: Thu, 14 Apr 2011 21:58:09 +1000
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 ThunderBrowse/3.3.5
MIME-Version: 1.0
To: Ole Markus With <olemarkus@olemarkus.org>
CC: "internals@lists.php.net" <internals@lists.php.net>
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> <4DA0E71C.9030008@gmail.com> <BANLkTi=jJTO3qgjN8=3DCKAV88pnvycVsA@mail.gmail.com> <op.vtp8l9jnr8a5bd@localhost> <4DA63ED8.4080402@yahoo.com.au> <op.vtw5fnjar8a5bd@localhost>
In-Reply-To: <op.vtw5fnjar8a5bd@localhost>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
From: mail_ben_schmidt@yahoo.com.au (Ben Schmidt)

>> 1. Suppression of notice. I agree, it is best done only for array
>> keys. It's not hard to initialise a variable with $var=null at the
>> beginning of a code block to avoid such a notice, and that is the
>> appropriate way to do it for variables.
>>
>> 2. Offering a shortcut for the common idiom isset($x) ? $x : $y in
>> line with the DRY design principle. A notice would never be emitted
>> here in any case. The problem is that this idiom is still in wide use
>> despite the shortcut ternary operator already provided, because an
>> isset() check is different to a boolean cast.
>>
>> Some thoughts:
>>
>> - The actual intent of 2. is probably $x!==null ? $x : $y i.e. it's
>> not about suppressing notices at all, but about offering a default
>> value, and the idiom quite probably only uses isset() because it
>> predated null in the language.
>>
> I have never felt the need for a shortcut in these cases. It would be
> interesting to see some code where this would be practical.

I have many, many uses for this. E.g. patterns like this:

class Foo {
    private $defaultBar;
    public function foobar(Bar $bar=null) {
       $bar = isset($bar) ? $bar : $this->defaultBar;
       $bar->doSomething();
    }
}

The default value of null indicates that the argument is able to be
omitted, and the type hinting mechanism understands that. Yet it's
awkward to actually test whether it's been omitted or not without
writing the argument multiple times. It'd be great to be able to write
the first line succinctly, e.g.

$bar $:= $this->defaultBar;

That's just one case. There are many more.

As I said above, though, I probably should have written $bar!==null
rather than isset($bar), because I actually would want the warning if
$bar was not defined (i.e. I had mistyped it).

>> - If we view 2. in this way, the two problems are independent, and it
>> seems to me it would be best to solve them independently, rather
>> than with a single operator.
>>
>> So, I suggest:
>>
>> 1. An array lookup mechanism that suppresses the notice for undefined
>> keys. It would work the same as regular array index lookups except
>> that the notice for undefined keys (and only for undefined keys)
>> would not be generated (it would not just be hidden, but would never
>> be even generated).
>
> This is what I feel PHP is missing. Particularly when it comes to
> multi-dimensional arrays. Because this feature is missing I tend to do
> something like
>
> function generateHash($x, $y, $z)
> {
> return "$x::$y::$z";
> }
>
> if (isset($a[generateHash($x, $y, $z)]) {
> ...
> }
>
> instead of
>
> if (isset($a[$x]) && isset($a[$x][$y]) && isset($a[$x][$y][$z])) {
> ...
> }

I don't really understand your example, or how an error-suppressing
array index lookup helps it, but I do think the feature is useful.

I actually think there is enough support for both these things, and
implementing them independently allows those who want to use one but not
the other to do so.

>> Arguing about syntax is then a second step. However, my views on this
>> are:
>
> I think it best to avoid discussing the actual syntax before agreeing on what we
> really need.

I agree. In fact I sent the previous mail by mistake; I had intended to
archive my thoughts on syntax and send the mail without them, but I
bumped send.

Ben.