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_schm...@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
>
>
