Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51897
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=G/P3dzELW19H+kH7DAbdwO7gkeu5odBwU9L5oFqkgi16lhf5KqEqrmaFOwMDM9ZcU3
         r5HB51NOd4qWVtNdcEgdZ/Eg9qrE50DDR0QhNOtZ2Dg2BR/+IcrTbXCf/nfsyz7cDBf7
         Vy1aR+iwL8gDzkpdAroBxNXejbSGNNiKJ63Ik=
MIME-Version: 1.0
In-Reply-To: <4DA6E151.4030707@yahoo.com.au>
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>
	<4DA6E151.4030707@yahoo.com.au>
Date: Thu, 14 Apr 2011 10:13:06 -0300
Message-ID: <BANLkTi=GupQCTAo-es2M-HuTnJLFL4N8mQ@mail.gmail.com>
To: Ben Schmidt <mail_ben_schmidt@yahoo.com.au>
Cc: Ole Markus With <olemarkus@olemarkus.org>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf307d015aa1323504a0e0affb
Subject: Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
From: martinscotta@gmail.com (Martin Scotta)

--20cf307d015aa1323504a0e0affb
Content-Type: text/plain; charset=ISO-8859-1

 Martin Scotta


On Thu, Apr 14, 2011 at 8:58 AM, Ben Schmidt
<mail_ben_schmidt@yahoo.com.au>wrote:

> 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();
>   }
> }
>

Bad example... you could get a Bar object or a null value, so I would
write...

class Foo {
private $defaultBar; /* initialized somewhere */
public function foobar(Bar $bar=null) {
if (null === $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.
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--20cf307d015aa1323504a0e0affb--