Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51988
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain yahoo.com.au from 98.139.91.79 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=y+VhvwS/AmmZvJ+imEGaifSLYMVGo1keJLQAhW0tZtLnFIG7z33kbAeuFxC02m/YNdBtiUmIKj1tu8M4/KBGA+G8RZEgDWY2dbR1zs/1MFaJtx02DEvdIWsGoEmxuwoYnLryghUpFtlCB0AdUChkLXReDhdEPlN7dHfMaiaRt1U=  ;
Message-ID: <4DB241FA.9040707@yahoo.com.au>
Date: Sat, 23 Apr 2011 13:05:30 +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: Martin Scotta <martinscotta@gmail.com>
CC: internals@lists.php.net
References: <AANLkTiknomAsTrsZ140rWs6CwxJP3UYGUokQbERhDiRp@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>	<4DB23915.1040503@yahoo.com.au> <BANLkTi=0zExN=gaanu3vvzbyxcbV0SE2ew@mail.gmail.com>
In-Reply-To: <BANLkTi=0zExN=gaanu3vvzbyxcbV0SE2ew@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)

It's good for some situations, but there are plenty more where it doesn't cut it, 
e.g. $_GET[?'foo'] $:= get_default_from_db('foo') $: "hard-coded".

Ben.



On 23/04/11 12:54 PM, Martin Scotta wrote:
> what about something like this?
>
>   $_GET += array( 'key' =>  42, 'other' =>  'blablah' );
>
> echo $_GET [ 'key' ];
>
> and it's already available on you current instalation :)
>
>   Martin Scotta
>
>
> On Fri, Apr 22, 2011 at 11:27 PM, Ben Schmidt<mail_ben_schmidt@yahoo.com.au
>> wrote:
>
>> 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.
>>
>>
>>
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>