Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51987
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.42 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
         :cc:content-type;
        b=tHw8BmUEy9Z96tzCMMnofXGusH5jYZdsho0Y9IPhUj2VidZTla09TaMimlr3MA1iKc
         LIqOK3L4/5pHB4VzE703L0g7rFiz4UvA0bBVn93UHgwYccpFzwkSTKedmgrjZ/kEGb2b
         r2r+oKThMvMm/U65xAszNDRuBo2Vcs8hsJHbk=
MIME-Version: 1.0
In-Reply-To: <4DB23915.1040503@yahoo.com.au>
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>
	<4DB23915.1040503@yahoo.com.au>
Date: Fri, 22 Apr 2011 23:54:36 -0300
Message-ID: <BANLkTi=0zExN=gaanu3vvzbyxcbV0SE2ew@mail.gmail.com>
To: Ben Schmidt <mail_ben_schmidt@yahoo.com.au>
Cc: Arpad Ray <arraypad@gmail.com>, Hannes Landeholm <landeholm@gmail.com>, internals@lists.php.net
Content-Type: multipart/alternative; boundary=0016e6d26dc54f5c6e04a18d18b2
Subject: Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
From: martinscotta@gmail.com (Martin Scotta)

--0016e6d26dc54f5c6e04a18d18b2
Content-Type: text/plain; charset=ISO-8859-1

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
>
>

--0016e6d26dc54f5c6e04a18d18b2--