Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51985
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain yahoo.com.au from 98.138.91.39 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=TXQo5AR/ruJ/W3IN2kZjwf+ga+uYYi2PImnGh1yXXsfuWPZMQygXWkzS+S36OXA2ie1xMunmxr/3dNx3DIHpM8CBFLQZo6U6StoLoqxBYmEjIJ7mMcwgZs4dPAXZJXvSMwAgs23RUCTtVPzT5T0cfN6zVwK9kUGEar+tsVp6OYE=  ;
Message-ID: <4DB23915.1040503@yahoo.com.au>
Date: Sat, 23 Apr 2011 12:27:33 +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: Arpad Ray <arraypad@gmail.com>
CC: Hannes Landeholm <landeholm@gmail.com>, internals@lists.php.net
References: <AANLkTiknomAsTrsZ140rWs6CwxJP3UYGUokQbERhDiRp@mail.gmail.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> <BANLkTinRpxgoYBc=H1uBqwLiCOmKA3zD+A@mail.gmail.com>
In-Reply-To: <BANLkTinRpxgoYBc=H1uBqwLiCOmKA3zD+A@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)

On 21/04/11 9:56 AM, Arpad Ray wrote:
> I must say that the prospect of yet more new syntax is scary. It
> really looks like Perl, and I wouldn't have the slightest clue what it
> meant if I'd missed the release notes.

I agree it looks a little bit strange. I think that's partly a benefit:
it doesn't look like something so that you assume you know what it means
but get it wrong; it drives you to the manual to find out what it means.

> I've pined for something like coalesce($_GET['foo'], $defaults['foo'],
> 42) for years, and I think that style is far more in keeping with the
> PHP ethos, and far more readily understandable than this suggested new
> syntax.

As I see it, there a are a number of drawbacks to this approach.

1. It doesn't help with a bunch of common paradigms. For instance,
$a['k'] = isset($a['k']) ? $a['k'] : "default"

2. I think it's too 'blunt'. For instance, if you write
coalesce($_GET['foo'], $defaults['foo']) you probably actually do want
to see a notice if $defaults['foo'] is not defined. But if you include
42 as a last resort default, you of course do not. Treating the last
argument of a variable number of arguments differently is difficult and
unintuitive, and even that would not always be desired anyway.
Furthermore with something like $o->foo are you interested in whether $o
is defined or not, or only in whether $o->foo is null? Particularly if
you have many arguments, if you don't have tests that give full coverage
of all the possibilities for each argument, notices very helpful for
debugging could be easily undesirably silenced.

3. It can't be equivalent to isset() on every argument. isset() is very
restricted in what it can operate on. For instance, isset(42) is not
legal; nor is isset(some_function()); and so on. This kind of thing
would be important to allow in coalescse(), but it would make things
difficult to parse: to have any chance of making it work, you'd need to
parse each item as if in isset(), and if it fails, backtrack and parse
it as an expression, and then the coalesce() operation(s) (it could not
be a function) would have to be able to deal with both scenarios for
every argument. Nasty.

4. It's misleading regarding side effects because it looks like a
function. If coalesce() were a function and you wrote
coalesce($_GET['foo'],get_default('foo')), you would expect
get_default() to be called before coalesce() and regardless of the state
of $_GET['foo']. If it actually behaved like that, it would render
coalesce() somewhat less useful, but it would be misleading if it didn't
work like that. isset() gets away with this because it is restricted and
only has one argument, but coalesce() wouldn't.

To avoid/solve these problems:

1. Support missing paradigms: I suppose adding coalesce_set() and other
constructs could conceptually provide for that.

2. Less blunt: You really need some kind of notice-free array index
and/or variable lookup that can pinpoint the notice to be omitted. A
function-like syntax doesn't really work: isset(), though better than
coalesce(), is still too blunt for many use cases. It's also very
verbose. Nobody wants to write
coalesce(ifset($_GET['foo']),ifset($defaults['foo']),42)
IMHO, it is better to have
coalesce($_GET[?'foo'],$defaults[?'foo'],42)
even though it's not 'familiar'.

3. Avoid isset()-like restrictions: You can use a !==null test that can
be applied to any expression; if problem 1 is solved satisfactorily, an
expression will simply be evaluated without generating a notice, and
then compared to null.

4. Sensible side-effect behaviour: To get that, you really need an
operator (or other language construct), and a function-like syntax is
misleading. Although unfamiliar,
$_GET[?'foo'] $: $defaults[?'foo'] $: 42
is less misleading. It also extends nicely to the assignment paradigm as
$_GET[?'foo'] $:= $defaults[?'foo'] $: 42;

Ben.