Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51904
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.170 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
         :content-type;
        b=UUFeOoL0cJ9jB9OC8myFDXG+xL/u5IyfeUY02mzAzzLrK6rC12aF7vjBKsumgf3+HN
         X2ijgB4dAILTlYz/YQyA3nOXPA+Tt7HZzpb33b/qovK2HI/B8PCaq9FIT0y1Gi5L22j0
         ScpG3Z3CqFYm2pj5WLTGY/U++lnm8Ph1ZEeOU=
MIME-Version: 1.0
In-Reply-To: <4DA703FB.3010603@yahoo.com.au>
References: <AANLkTiknomAsTrsZ140rWs6CwxJP3UYGUokQbERhDiRp@mail.gmail.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>
	<4DA6F2BC.10706@yahoo.com.au>
	<BANLkTi=4SD2fzwMc5uLquBkHeBmxDRC0DA@mail.gmail.com>
	<4DA6FB03.9040404@yahoo.com.au>
	<BANLkTimiH2vYWEY8JAf0P_GD81AqGmStDQ@mail.gmail.com>
	<4DA703FB.3010603@yahoo.com.au>
Date: Thu, 14 Apr 2011 17:01:43 +0200
Message-ID: <BANLkTi=EZGsCtH0hvK1JntKbW2o69tES4w@mail.gmail.com>
To: Ben Schmidt <mail_ben_schmidt@yahoo.com.au>, internals@lists.php.net
Content-Type: multipart/alternative; boundary=0016369201d514fc5704a0e23431
Subject: Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
From: landeholm@gmail.com (Hannes Landeholm)

--0016369201d514fc5704a0e23431
Content-Type: text/plain; charset=ISO-8859-1

I can agree that implementing ?? with isset() and not array_key_exists()
would be acceptable... but empty() is a blunt compromise and much less
used... The general problem is the notice being thrown when array indexes
doesn't exist - which results in code duplication when you deal with it
nicely. empty() tries to be a generic solution but there will always be
people that has some other special definition of "emptiness" like "array
that contains a single null value" and they need to write the code that
defines that particular comparison anyway.

You can't have a solution that makes everything easier for everyone so let's
solve one thing at a time and start with the most generic problem
specifically and not all minor problems that happens to partially intersect
that one.

~Hannes


On 14 April 2011 16:26, Ben Schmidt <mail_ben_schmidt@yahoo.com.au> wrote:

> On 15/04/11 12:05 AM, Hannes Landeholm wrote:
>
>> Trying to summarize this discussion... I think we can all agree that the
>> main problem is "code duplication for array access when parameters are
>> possibly not existing".
>>
>
> For me the problem is 'code duplication when a value might be null'
> (whether an array, variable or something else, and regardless of whether
> it was set to null, or not defined at all).
>
>
>  I think we all can also agree that @ can be both used properly and
>> misused - and it is a blunt tool and not a nice solution to the
>> previously stated problem.
>>
>
> Yes.
>
>
>  Some suggested that the ternary if comparison should suppress the notice
>> automatically. This would break existing code and also be confusing since
>> people expect a ternary if and normal if to work the same way.
>>
>
> Yes.
>
>
>  Some suggested ?? as an array access operator that suppresses the notice
>> and
>> has 3 variants: A: nothing specified - uses null as default, B: has
>> default
>> specified, C: returns X if index exists or Y if index doesn't exist. This
>> effectively solves the code duplication problem and is a shortcut for
>> saying
>> "the array index may or may not exist".
>>
>
> This only works if the test is made an isset() kind of test. If it
> remains a boolean cast, it doesn't help much. (Or at least it doesn't
> help me much.)
>
> I also think it's a bit too blunt. In all but the simplest expressions
> in the condition, desired notices could be silenced. I like the idea of
> being able to specify exactly which array lookups should be silenced.
>
> It also doesn't help the people who want an isset() style test, but
> without the notice suppression, and I think there are a few people in
> that category.
>
>
>  One person said that the relation between ? and ?? and == and === would
>> make
>> the operator non-intuitive. Other people disagreed and claimed the
>> opposite.
>>
>> So basically the discussion now is what exact characters that should be
>> used
>> to represent this operator? I really hope we can get this implemented
>> quickly... I worked with $_POST yesterday and I could really use that ??
>> operator.
>>
>
> I still don't think we've reached agreement on exactly what we need.
> Your summary seems to me to be of some of the earliest and least
> developed ideas. I think the discussion has moved in a number of
> interesting directions since then and we should draw on that later work.
>
> Ben.
>
>
>
>

--0016369201d514fc5704a0e23431--