Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51912
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain yahoo.com.au from 98.139.213.154 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=ZxBl/TDbi0w5arJm9x/BQ7w1lnN5z4nkE/KAVc8nFMFuiTN2g7ubwwf1DP2gtU9/wt+89UdQgZvHV0hheGXcPs0YWnJcGEEGIWMPkIKNsCT+fFKtbs6v3GM3Gaq7bG+iDA7bcvvPSzNOmGjfjZYpZyJ0hHkWXxUcdF4/ROR3fJA=  ;
Message-ID: <4DA8E468.8090707@yahoo.com.au>
Date: Sat, 16 Apr 2011 10:35:52 +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: Hannes Landeholm <landeholm@gmail.com>
CC: internals@lists.php.net
References: <AANLkTiknomAsTrsZ140rWs6CwxJP3UYGUokQbERhDiRp@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>	<BANLkTi=EZGsCtH0hvK1JntKbW2o69tES4w@mail.gmail.com>	<4DA798DE.1060805@yahoo.com.au> <BANLkTi=5iTJecJqpRZirCPKY+vT30eiNQg@mail.gmail.com>
In-Reply-To: <BANLkTi=5iTJecJqpRZirCPKY+vT30eiNQg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; 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)

That sounds fine to me, and the extension to ArrayAccess is really
clever. I agree that 'take more care' is a better way to view the array
access. It means both the array access should be more careful (to check
and avoid errors, rather than just proceed), and also the 'caller'
should be more careful by being more prepared to accept null values. I
don't know if ? is the best character to represent this, but I don't
really care--I'd just be glad of the functionality. Perhaps ! is another
possibility worth considering, though.

If 7 and 8 are included, there are actually then four new constructs:

- $: operator that evaluates to LHS if !==null, RHS otherwise
- $:= assignment only if the LHS is null or undefined (return final LHS)
- ?[...] array index lookup without notice (and ArrayAccess extension)
- $?name variable lookup without notice

I'd be happy with that. The only one I'm not so sure about is the last
one.

Ben.

(P.S. My earlier example for 7 was slightly wrong; it should require
what is now the ?[...] construct to avoid the notice; other compound
assignment operators like += produce notices. I've modified it below.)



On 15/04/11 8:12 PM, Hannes Landeholm wrote:
> I like this - especially .7 and .8.
>
> The $: is intuitive because it looks like a variable that doesn't contain
> anything and the : specifies what comes then.
>
> However I'd rather use the "?" character than "@" for the simple reason that
> I see this as a more careful way to access an array and not as an "error
> silencing operation". E.g. it's not implemented by setting error reporting
> to 0 but rather... to illustrate it, let's pretend that the PHP array where
> implemented by the ArrayAccess class. The "offsetGet" signature would be
> changed too take an extra argument:
>
> offsetGet( mixed $offset, boolean $unset_defined )
>
> Normal array access would have $unset_defined set to false, but an access
> like $a?[$k] would set it to true (the ?[ modifier) would make
> $unset_defined become true so:
>
> if (!$unset_defined) {
> \trigger_error("Undefined index: $offset", \E_NOTICE);
> }
> return null;
>
> Of course, in userland, one could implement ArrayAccess and exploit the
> $unset_defined parameter in any other way. Let's for example say that you
> implement it to make an ArrayAccess class that maps data to the file system,
> using the file name as a $offset. If $unset_defined is set to false you
> would just go ahead and try to open the file in question, possibly raising a
> file operation error - however if $unset_defined is true you might make a
> careful check before opening the file to see if it really exist. If error
> silencing would be used instead - other errors like file permission errors
> could incorrectly be silenced - but $unset_defined specifically checks if
> the file exist or not before access. So it could affect the read operation
> itself - and I hope that explains why It's more than just "error silencing".
>
> ~Hannes
>
> On 15 April 2011 03:01, Ben Schmidt<mail_ben_schmidt@yahoo.com.au>  wrote:
>
>> I agree empty() is basically useless. We already have the existing
>> ternary operator (and its shortcut) to do a boolean test, which is
>> basically the same as empty().
>>
>> The way I see it, if rather than making an isset() operator that
>> suppresses errors and offers a default, we added both a !==null operator
>> for the default, and a separate error-suppression mechanism, people
>> could use the suppression mechanism with the existing boolean ternary
>> operator if they want to (I would find that useful, as I often write
>> things such as isset($a[$k])&&$a[$k]?"yes":"no" for that kind of thing),
>> and use the !==null operator without error suppression (I would find
>> that useful, too, to avoid typos).
>>
>> In summary, with two separate, simpler mechanisms, we could tackle these
>> paradigms (I have used @[...] for undefined index error-suppression and
>> $: for !==null default):
>>
>> 1. $v!==null ? $v : "default"
>>    $v $: "default"
>>    with notice
>>
>> 2. $a[$k]!==null ? $a[$k] : "default"
>>    $a[$k] $: "default"
>>    with notice
>>
>> 3. isset($a[$k]) ? $a[$k] : "default"
>>    $a@[$k] $: "default"
>>    without notice
>>
>> 4. isset($a[$k]) ? $a[$k] : null
>>    $a@[$k]
>>    without notice
>>
>> 5. isset($a[$k])&&!!$a[$k]
>>    !!$a@[$k]
>>    without notice
>>
>> 6. isset($a[$k])&&$a[$k] ? "yes" : "no"
>>    $a@[$k] ? "yes" : "no"
>>    without notice
>>
>> With !==null assignment (I've used $:=) we could also have:
>>
>> 7. if (!isset($a[$k])) $a[$k] = "default";
>>    $a@[$k] $:= "default";
>>    without notice
>>
>> To avoid encouraging poor coding, we would deliberately not have:
>>
>> 8. isset($v) ? $v : "default"
>>    $@v $: "default"
>>    without notice
>>
>> But it is a cinch to add it if enough people want it, and doing so
>> wouldn't affect anyone who didn't want to use it--no backward
>> compatibility problems on the horizon. I think that's the clincher. If
>> we just add an isset() operator (that suppresses errors, and gives a
>> default), we only get paradigms 3, 4, 5 and maybe 7, but worse, if we
>> want to add any of the others later, we need to design more complicated
>> new operators, or break backward compatibility, not just extend what we
>> have.
>>
>> I personally use 1, 3, 5 and 6 quite often, and 2 and 7 occasionally, so
>> I see great value in being able to do them all, not just the restricted
>> set.
>>
>> What numbers are others interested in being able to solve?
>>
>> What do others think about the future-proofing issue?
>>
>> Ben.