Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51896
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.248 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=lodeLT2S0P1cRIrgrlHCWOeRJZttHCsUBil2QiiU92NsMIcxhEzx6qU1AXFj1dek/nCHKrYXiC0LsiVip2pVn1IvmGupcrHbMHREZNNHVmK4EDKkzj/OHPiDE5CQAhZZj6wHWzJXIep8/bZaGXclaP6zmtcqPjWJK6ydHTZpdc0=  ;
Message-ID: <4DA6F2BC.10706@yahoo.com.au>
Date: Thu, 14 Apr 2011 23:12:28 +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: RQuadling@googlemail.com
CC: Richard Quadling <rquadling@gmail.com>,
  Eloy Bote Falcon <eloybote@gmail.com>,
  Ole Markus With <olemarkus@olemarkus.org>,
  "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> <BANLkTi=jFJpqEX+8_yiCZbKVkYc1+EhnSw@mail.gmail.com> <BANLkTinPUnzXpfj8AVeaUBi1YSgveCzrPA@mail.gmail.com>
In-Reply-To: <BANLkTinPUnzXpfj8AVeaUBi1YSgveCzrPA@mail.gmail.com>
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)

>>>> There are two issues here.
>>>>
>>>>     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.
>>>>
>>>>     - 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).
>>>>
> http://news.php.net/php.internals/51877
>
> array_key_exists($key, $array) for arrays
> array_key_exists($varname, get_defined_vars()) for locally scoped variables.

Apart from being long and ugly, surely that is horribly inefficient.

> No need to use @.

True. And I don't think anybody is. We all know @ is dangerous and nasty
and don't use it. We're not seeking an alternative to @, we're seeking
an alternative to repeating ourselves by using
isset()/array_key_exists()/is_null() as well as the value being tested.

But we don't want to do this in a blanket way similar to @ where a whole
bunch of notices are suppressed. We want to specify precisely where
missing values are allowable by indicating exactly which array index
lookups may silently fail (and evaluate to null).

Basically we don't want to make again the mistake that @ was.

> Are they attempting to determine the existence of a variable/index
> entry or are they attempting to determine if the variable/element is
> null.

For me, existence and nullness are basically the same, and I think this
is the common case. The whole point of being able to set something to
null is to have a 'value' to represent 'unsetness'. This is why I think
solving the conditional problem should use a !==null test. That gives
the flexibility to use/pass null to represent 'unsetness' but doesn't
pick up zero, false, etc. like a boolean cast does. Using
array_key_exists() would remove that flexibility and be less useful.

As far as silencing notices goes, the rationale is that basically we
want to flag that 'null is OK, even if it's a fallback'. I.e. we don't
care whether a value is null because it was set to null, or because null
is a fallback because the variable was never defined. Either way, null
is OK, so don't tell me about it.

The conditional side lets us handle nulls nicely by providing our own
defaults/fallbacks if it appears. The notice-suppression side lets us
say that null is OK, even if that null itself is a fallback for
'undefined'. Quite often they will be used in combination, but they are
independent.

> I always declare my variables. So, I don't want to use isset() as they
> will be an incorrect test. I use is_null(). Specifically testing the
> value. If I've made a mistake and NOT declared the variable (or made a
> typo), I want to know. I don't want to hide it with isset()/empty().

That's exactly why I think the conditional should use a !==null test,
not an isset() test.

Ben.