Everything

php

Home » Project » Newsgroups » php.internals » Re: what happened to that new isset() like language construct »

Re: what happened to that new isset() like language construct

php.internals

Jason Garber

22 years ago

Hi Marc,

What we basically settled on was to use this syntax (as a new language
construct):

$x = ifsetor(mixed variable, mixed default);

If I recall correctly, Marcus had a patch that implemented it and it was
going to be plugged in in the 4.1 branch (when it is created).

I'm eagerly waiting for it also  :)

Sincerely,
Jason Garber

At 7/7/2004 08:26 PM -0400, Marc Richards wrote:

Marc Richards

22 years ago

Jason Garber wrote:

> Hi Marc,
>
> What we basically settled on was to use this syntax (as a new language
> construct):
>
> $x = ifsetor(mixed variable, mixed default);

So ?: is out then?  Or just delayed until it can be tackled.

> If I recall correctly, Marcus had a patch that implemented it and it was
> going to be plugged in in the 4.1 branch (when it is created).

5.1?

Jason Garber

22 years ago

Hi Marc,

At 7/7/2004 09:06 PM -0400, Marc Richards wrote:

>Jason Garber wrote:
>
>>Hi Marc,
>>What we basically settled on was to use this syntax (as a new language
>>construct):
>>$x = ifsetor(mixed variable, mixed default);
>
>So ?: is out then?  Or just delayed until it can be tackled.

Who am I to say it's out for good?  :)

I just thought that the general consensus was a function like call, rather
than a new operator.  I do remember that there was fairly strong support
for both, but there were various disadvantages to a new operator vs a new
"function" call.

On a related note, does anyone know when 5.1 is going to be
branched?   Shortly after the 5.0.0 release, I assume.

>>If I recall correctly, Marcus had a patch that implemented it and it was
>>going to be plugged in in the 4.1 branch (when it is created).
>
>5.1?

Yep.

>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php

-Jason

Andi Gutmans

22 years ago

At 09:20 PM 7/7/2004 -0400, Jason Garber wrote:

>On a related note, does anyone know when 5.1 is going to be
>branched?   Shortly after the 5.0.0 release, I assume.

Yeah I'd like to branch 5.0 off right away as there are some things I'd
like to start working on, mainly some performance patches.

Andi

Christian Schneider

22 years ago

Jason Garber wrote:

> What we basically settled on was to use this syntax (as a new language
> construct):
> $x = ifsetor(mixed variable, mixed default);

Before it gets forgotten: I still think that
$x = ifsetor(mixed var, mixed var [, ...]);
with expressions in all parts is the way to go.

Example usage:
$a = ifsetor($_REQUEST['x'], $db->get('x'), 'default_x');

This needs some work to disable warnings because of unset values inside
the ifsetor() but would provide a lot of value.

And I also think that the name ifsetor has to be reevaluated :-)

- Chris

Marc Richards

22 years ago

Christian Schneider wrote:

> Before it gets forgotten: I still think that
> $x = ifsetor(mixed var, mixed var [, ...]);
> with expressions in all parts is the way to go.
>
> Example usage:
> $a = ifsetor($_REQUEST['x'], $db->get('x'), 'default_x');
>

The other syntax could work for that as well...

$a = $_REQUEST['x'] ?: $db->get('x') ?: 'default_x';

and with a little white-space it is even more readable:

$a = $_REQUEST['x']  ?:  $db->get('x')  ?:  'default_x';

Marc

Rasmus Lerdorf

22 years ago

On Thu, 8 Jul 2004, Marc Richards wrote:

> Christian Schneider wrote:
>
> > Before it gets forgotten: I still think that
> > $x = ifsetor(mixed var, mixed var [, ...]);
> > with expressions in all parts is the way to go.
> >
> > Example usage:
> > $a = ifsetor($_REQUEST['x'], $db->get('x'), 'default_x');
> >
>
> The other syntax could work for that as well...
>
> $a = $_REQUEST['x'] ?: $db->get('x') ?: 'default_x';
>
>
> and with a little white-space it is even more readable:
>
> $a = $_REQUEST['x']  ?:  $db->get('x')  ?:  'default_x';

That syntax is way too confusing.

Spotting the difference between:

$a = $b ?: $c ?: $d;

$a = $b ? $c : $d;

is non-trivial and the two would do completely different things.

This needs to be a function that people can easily look up in the
documentation.

-Rasmus

Marc Richards

22 years ago

Rasmus Lerdorf wrote:

> On Thu, 8 Jul 2004, Marc Richards wrote:
>
>>Christian Schneider wrote:
>>
>>
>>>Before it gets forgotten: I still think that
>>>$x = ifsetor(mixed var, mixed var [, ...]);
>>>with expressions in all parts is the way to go.
>>>
>>>Example usage:
>>>$a = ifsetor($_REQUEST['x'], $db->get('x'), 'default_x');
>>>
>>
>>The other syntax could work for that as well...
>>
>>$a = $_REQUEST['x'] ?: $db->get('x') ?: 'default_x';
>>
>>
>>and with a little white-space it is even more readable:
>>
>>$a = $_REQUEST['x']  ?:  $db->get('x')  ?:  'default_x';
>
>
> That syntax is way too confusing.
>
> Spotting the difference between:
>
>   $a = $b ?: $c ?: $d;
>
>   $a = $b ? $c : $d;
>
> is non-trivial and the two would do completely different things.

That is true for other things as well:

$a = $b += $c += $d;

$a = $b + $c = $d;

That doesn't make them inheritly evil.  Adding white-space and brackets
can make it even more readable.

$a = ($b ?:  ($c ?: $d));

$a = ($b ? $c : $d);

> This needs to be a function that people can easily look up in the
> documentation.

Does it?  There are other similar constructs that don't e.g. +=, $a ? $b
: $c, .=;

I think that part of the reason that these things are so terse is
because if would defeat the whole point to use a function name; The aim
is to be concise.

If what marcus says about only being able to take two areguments is
true, then it makes an even stronger case, lest we end up with:

$a = ifsetor($b, ifsetor($c, $d));


Marc

Rasmus Lerdorf

22 years ago

On Thu, 8 Jul 2004, Marc Richards wrote:

> Does it?  There are other similar constructs that don't e.g. +=, $a ? $b
> : $c, .=;

These have roots in other languages and as such have a familiarity to
them.  ?: would be a brand new operator nobody has seen before and one
that looks a lot like the ternary operator which everyone knows about.

> I think that part of the reason that these things are so terse is
> because if would defeat the whole point to use a function name; The aim
> is to be concise.

No, the aim is not conciseness.  That has never been PHP's goal.  The aim
is clarity.

-Rasmus

Marc Richards

22 years ago

Rasmus Lerdorf wrote:

> On Thu, 8 Jul 2004, Marc Richards wrote:
>
>>Does it?  There are other similar constructs that don't e.g. +=, $a ? $b
>>: $c, .=;
>
>
> These have roots in other languages and as such have a familiarity to
> them.  ?: would be a brand new operator nobody has seen before and one
> that looks a lot like the ternary operator which everyone knows about.
>

We can always create a name for the construct (in the same way the
ternary statement has a name) and properly document it.  If it becomes
useful and popular, people will start calling it that.  Proper
documentation doesn't require an actual function name.

>>I think that part of the reason that these things are so terse is
>>because if would defeat the whole point to use a function name; The aim
>>is to be concise.
>
>
> No, the aim is not conciseness.  That has never been PHP's goal.  The aim
> is clarity.
>

I wasn't saying it was a PHP goal, I was it is the goal of certain
constructs like += or .=


Marc

Rasmus Lerdorf

22 years ago

On Thu, 8 Jul 2004, Marc Richards wrote:

> Rasmus Lerdorf wrote:
> > On Thu, 8 Jul 2004, Marc Richards wrote:
> >
> >>Does it?  There are other similar constructs that don't e.g. +=, $a ? $b
> >>: $c, .=;
> >
> >
> > These have roots in other languages and as such have a familiarity to
> > them.  ?: would be a brand new operator nobody has seen before and one
> > that looks a lot like the ternary operator which everyone knows about.
> >
>
> We can always create a name for the construct (in the same way the
> ternary statement has a name) and properly document it.  If it becomes
> useful and popular, people will start calling it that.  Proper
> documentation doesn't require an actual function name.

That wasn't my point.  The point was that every operator in PHP is common
and known to the majority of people familiar with any other language.  You
are proposing adding a new operator never seen before.  Giving it a name
won't help because how will people know this name?  The way you name an
operator is to make it a function.

> >>I think that part of the reason that these things are so terse is
> >>because if would defeat the whole point to use a function name; The aim
> >>is to be concise.
> >
> > No, the aim is not conciseness.  That has never been PHP's goal.  The aim
> > is clarity.
>
> I wasn't saying it was a PHP goal, I was it is the goal of certain
> constructs like += or .=

+= is not unique to PHP in any way.  Pick 10 random mediocre PHP or
non-PHP developers out of a crowd and ask then what += does and I bet a
good number will be able to tell you.  Do the same with ?: and you will
first have to carefully explain that no, this is not the ternary ? :
operator, but rather a single ?: operator and then ask them to guess at
what it might do.  How many do you think will figure it out?

We don't do things to save people typing a couple of extra characters here
and there.  We do things to lower the WTF factor of the language as much
as possible.  The overall design from the very beginning has been to meet
the expectations of the common developer.  The common developer expects
common operators such as += ++ -- != to do the right things.  Not having
these would give us a high WTF factor.  Nobody in the world expects a ?:
operator which is not the ternary operator.  And having such an operator
would indeed be a big surprise and as such its WTF factor is high.

-Rasmus

Marc Richards

22 years ago

Rasmus Lerdorf wrote:

> On Thu, 8 Jul 2004, Marc Richards wrote:
>
>>Rasmus Lerdorf wrote:
>>
>>>On Thu, 8 Jul 2004, Marc Richards wrote:
>>>
>>>
>>>>Does it?  There are other similar constructs that don't e.g. +=, $a ? $b
>>>>: $c, .=;
>>>
>>>
>>>These have roots in other languages and as such have a familiarity to
>>>them.  ?: would be a brand new operator nobody has seen before and one
>>>that looks a lot like the ternary operator which everyone knows about.
>>>
>>
>>We can always create a name for the construct (in the same way the
>>ternary statement has a name) and properly document it.  If it becomes
>>useful and popular, people will start calling it that.  Proper
>>documentation doesn't require an actual function name.
>
>
> That wasn't my point.  The point was that every operator in PHP is common
> and known to the majority of people familiar with any other language.  You
> are proposing adding a new operator never seen before.  Giving it a name
> won't help because how will people know this name?

They won't.  Not until they hear about it or read about it.  But that is
true whether it is a function or and operator.  Making it a function
won't make everyone magically cogniscent of it.  Of course it will be
important to make it easy to search for information about it on PHP.net,
which includes allowing people to search for ?: and providing a courtesy
link from the ternary operator section.

>The way you name an operator is to make it a function.

Huh? I must be misunderstanding what you mean to say, because as far as
I can tell that just isn't true otherwise we would have functions like
add(), subtract() and ternary().

>>>>I think that part of the reason that these things are so terse is
>>>>because if would defeat the whole point to use a function name; The aim
>>>>is to be concise.
>>>
>>>No, the aim is not conciseness.  That has never been PHP's goal.  The aim
>>>is clarity.
>>
>>I wasn't saying it was a PHP goal, I was it is the goal of certain
>>constructs like += or .=
>
>
> += is not unique to PHP in any way.  Pick 10 random mediocre PHP or
> non-PHP developers out of a crowd and ask then what += does and I bet a
> good number will be able to tell you.  Do the same with ?: and you will
> first have to carefully explain that no, this is not the ternary ? :
> operator, but rather a single ?: operator and then ask them to guess at
> what it might do.  How many do you think will figure it out?
>
> We don't do things to save people typing a couple of extra characters here
> and there.  We do things to lower the WTF factor of the language as much
> as possible.  The overall design from the very beginning has been to meet
> the expectations of the common developer.  The common developer expects
> common operators such as += ++ -- != to do the right things.

Are you saying PHP will never introduce an operator that doesn't already
exist in a large number of other languages?

> Not having
> these would give us a high WTF factor.  Nobody in the world expects a ?:
> operator which is not the ternary operator.  And having such an operator
> would indeed be a big surprise and as such its WTF factor is high.
>

To be honest I am kinda hot and cold about how close it is to the
ternary operator.  On the one hand the two could be easily confused, but
on the other hand they are in fact very similar in function in which
case we could "market" (meaning document) them as being related.

Ternary operator:

$a = $b ? $b : $c;

Compound Ternary operator:

$a = $b ?: $c;


The only asymmetry being that the "compound ternary operator" doesn't
throw and error if !isset($b) whereas the regular one does...deal
breaker? I dunno.


Marc

Adam Maccabee Trachtenberg

22 years ago

On Thu, 8 Jul 2004, Marc Richards wrote:

> Are you saying PHP will never introduce an operator that doesn't already
> exist in a large number of other languages?

I certainly hope not. (Well, I guess === and !=== are exceptions to
this statement.)

> Compound Ternary operator:
>
> $a = $b ?: $c;

You realize that ternary means it takes three arguments? It has
nothing to do with question marks and colons. Your new "compound
ternary" operator is really a "binary" operator.

-adam

--
adam@trachtenberg.com
author of o'reilly's "upgrading to php 5" and "php cookbook"
avoid the holiday rush, buy your copies today!

Johannes Schlueter

22 years ago

Marc Richards wrote:

> They won't.  Not until they hear about it or read about it.  But that is
> true whether it is a function or and operator.  Making it a function
> won't make everyone magically cogniscent of it.  Of course it will be
> important to make it easy to search for information about it on PHP.net,
> which includes allowing people to search for ?: and providing a courtesy
> link from the ternary operator section.

And if they read about it they start searching. And many people know how to
search for http://php.net/functionname, which works well, but searching for
http://php.net/?: would result in the index.php. So the user needs to
search through the manual and without knowing the name of the operator it's
hard for to seperate between "? :" and "?:".

I'd like the ?:-Syntax very much but I'm not sure wether it realy fits into
PHP - PHP is not Perl ;-)

johannes

Marcus Börger

22 years ago

Hello Marc,

Friday, July 9, 2004, 1:33:02 AM, you wrote:

> Rasmus Lerdorf wrote:

>> On Thu, 8 Jul 2004, Marc Richards wrote:
>>
>>>Rasmus Lerdorf wrote:
>>>
>>>>On Thu, 8 Jul 2004, Marc Richards wrote:
>>>>
>>>>
>>>>>Does it?  There are other similar constructs that don't e.g. +=, $a ? $b
>>>>>: $c, .=;
>>>>
>>>>
>>>>These have roots in other languages and as such have a familiarity to
>>>>them.  ?: would be a brand new operator nobody has seen before and one
>>>>that looks a lot like the ternary operator which everyone knows about.
>>>>
>>>
>>>We can always create a name for the construct (in the same way the
>>>ternary statement has a name) and properly document it.  If it becomes
>>>useful and popular, people will start calling it that.  Proper
>>>documentation doesn't require an actual function name.
>>
>>
>> That wasn't my point.  The point was that every operator in PHP is common
>> and known to the majority of people familiar with any other language. You
>> are proposing adding a new operator never seen before.  Giving it a name
>> won't help because how will people know this name?

> They won't.  Not until they hear about it or read about it.  But that is
> true whether it is a function or and operator.  Making it a function
> won't make everyone magically cogniscent of it.  Of course it will be
> important to make it easy to search for information about it on PHP.net,
> which includes allowing people to search for ?: and providing a courtesy
> link from the ternary operator section.

>>The way you name an operator is to make it a function.

> Huh? I must be misunderstanding what you mean to say, because as far as
> I can tell that just isn't true otherwise we would have functions like
> add(), subtract() and ternary().

>>>>>I think that part of the reason that these things are so terse is
>>>>>because if would defeat the whole point to use a function name; The aim
>>>>>is to be concise.
>>>>
>>>>No, the aim is not conciseness.  That has never been PHP's goal.  The aim
>>>>is clarity.
>>>
>>>I wasn't saying it was a PHP goal, I was it is the goal of certain
>>>constructs like += or .=
>>
>>
>> += is not unique to PHP in any way.  Pick 10 random mediocre PHP or
>> non-PHP developers out of a crowd and ask then what += does and I bet a
>> good number will be able to tell you.  Do the same with ?: and you will
>> first have to carefully explain that no, this is not the ternary ? :
>> operator, but rather a single ?: operator and then ask them to guess at
>> what it might do.  How many do you think will figure it out?
>>
>> We don't do things to save people typing a couple of extra characters here
>> and there.  We do things to lower the WTF factor of the language as much
>> as possible.  The overall design from the very beginning has been to meet
>> the expectations of the common developer.  The common developer expects
>> common operators such as += ++ -- != to do the right things.

> Are you saying PHP will never introduce an operator that doesn't already
> exist in a large number of other languages?

>> Not having
>> these would give us a high WTF factor.  Nobody in the world expects a ?:
>> operator which is not the ternary operator.  And having such an operator
>> would indeed be a big surprise and as such its WTF factor is high.
>>

> To be honest I am kinda hot and cold about how close it is to the
> ternary operator.  On the one hand the two could be easily confused, but
> on the other hand they are in fact very similar in function in which
> case we could "market" (meaning document) them as being related.

> Ternary operator:

> $a = $b ? $b : $c;

> Compound Ternary operator:

> $a = $b ?: $c;

> The only asymmetry being that the "compound ternary operator" doesn't
> throw and error if !isset($b) whereas the regular one does...deal
> breaker? I dunno.

AND ?: won't be ternary....the whole reason for that operators name is that
obviously noone had a good name for it. But since it is the only ternary
operator (at least in all the languages i know) everybody calls the
construct ternary operator.

--
Best regards,
Marcus                            mailto:helly@php.net

Bob Glamm

22 years ago

> To be honest I am kinda hot and cold about how close it is to the
> ternary operator.  On the one hand the two could be easily confused, but
> on the other hand they are in fact very similar in function in which
> case we could "market" (meaning document) them as being related.
>
> Ternary operator:
>
> $a = $b ? $b : $c;
>
> Compound Ternary operator:
>
> $a = $b ?: $c;

Not that my opinion makes much difference, but from an
end-user/developer point of view, overloading ?: is not a
good idea:

a) Every other language that uses ?: (and there are a fair number of
them) gives it the same behavior: if/then/else.  Adding additional
functionality to ?: would be entirely unexpected.

b) Upon seeing this initially, my first guess at functionality:

$a = $b ?: $c;

My guess is that it would imply that $a is set to NULL or
becomes undefined in the case that $b evaluates to true, and set to $c
if $b evaluates to false.

Note that this is completely different from what actually happens.
In this instance, if I've not encountered the operator before,
I'm more likely to assume that my guess at its functionality
is correct.  However, if it's

$a = function_name($b, $c);

I'll immediately go to www.php.net/manual to look up
'function_name'.

As far as introducing operators to PHP that have no equivalents in
other common languages: IMHO you'd need a very strong case to introduce
them for precisely the two reasons outlined above, most likely
some new programming paradigm that occurs often enough and
is similar enough in functionality to one of the current set of operators
to justify using an operator as a shortcut for it.

-Bob

Rasmus Lerdorf

22 years ago

On Thu, 8 Jul 2004, Marc Richards wrote:

> Are you saying PHP will never introduce an operator that doesn't already
> exist in a large number of other languages?

That's a good rule.  Over the 10 years of PHP development we have followed
this with the only exception being the === operators for checking for
"really equal".

-Rasmus

Olivier Hill

22 years ago

Marc Richards wrote:

>
> That is true for other things as well:
>
> $a = $b += $c += $d;
>
> $a = $b + $c = $d;

Well.. yes and no...

If you are afraid of making mistake, you can force yourself to never use
+= -= *= operators, because you can simply write $a = $a + $b

But if PHP introduces the ?: operator, you have to use it and there is
no other way around.

As for others, I am +1 on the function name. I really think PHP should
not have fuzzy operators like in Perl. Can you easily tell me what ||=
(or something similar) does in Perl?

Olivier

--
GB/E/IT d+ s+:+ a-- C++$ UL++++$ P++++ L+++$ E- W++$ N- ?o ?K w--(---)
!O M+$ V- PS+ PE- Y PGP t++ 5-- X+@ R- tv++ b++(+++) DI++++ D+ G++ e+>++
h(*) r y+(?)

Marc Richards

22 years ago

Olivier Hill wrote:

> Marc Richards wrote:
>
>>
>> That is true for other things as well:
>>
>> $a = $b += $c += $d;
>>
>> $a = $b + $c = $d;
>
>
> Well.. yes and no...
>
> If you are afraid of making mistake, you can force yourself to never use
> += -= *= operators, because you can simply write $a = $a + $b
>
> But if PHP introduces the ?: operator, you have to use it and there is
> no other way around.

What? Why? There is obviously a way around it, because that is what
people are using now.

$a = $b ? $b : $c;

Marc

Olivier Hill

22 years ago

Marc Richards wrote:

>
> What? Why? There is obviously a way around it, because that is what
> people are using now.
>
> $a = $b ? $b : $c;

If $b is not set, it will throw notices.

The correct way is something similar to:

$a = (!isset($b) && !isnull($b)) ? $b : $c

Which defeats the whole reason of introducing the new ifsetor() operator.

Sincerely,
Olivier

--
GB/E/IT d+ s+:+ a-- C++$ UL++++$ P++++ L+++$ E- W++$ N- ?o ?K w--(---)
!O M+$ V- PS+ PE- Y PGP t++ 5-- X+@ R- tv++ b++(+++) DI++++ D+ G++ e+>++
h(*) r y+(?)

Marc Richards

22 years ago

Olivier Hill wrote:

> Marc Richards wrote:
>
>>
>> What? Why? There is obviously a way around it, because that is what
>> people are using now.
>>
>> $a = $b ? $b : $c;
>
>
> If $b is not set, it will throw notices.
>
> The correct way is something similar to:
>
> $a = (!isset($b) && !isnull($b)) ? $b : $c
>

Right. Sorry. I meant.

$a = isset($b) ? $b : $c;

But my point is that you won't be FORCED to use the new operator, just
like you aren't FORCED to use +=.

Marc

Derick Rethans

22 years ago

On Thu, 8 Jul 2004, Marc Richards wrote:

> Right. Sorry. I meant.
>
> $a = isset($b) ? $b : $c;
>
>
> But my point is that you won't be FORCED to use the new operator, just
> like you aren't FORCED to use +=.

I think it simply boils down to this:
- PHP *developers* want a function for it.

regards,
Derick

Unnamed Person

22 years ago

Christian Schneider <cschneid@cschneid.com> writes:

> Before it gets forgotten: I still think that
> $x = ifsetor(mixed var, mixed var [, ...]);
> with expressions in all parts is the way to go.
>
> Example usage:
> $a = ifsetor($_REQUEST['x'], $db->get('x'), 'default_x');
>
> And I also think that the name ifsetor has to be reevaluated :-)

This is the exact usage and meaning of the SQL function coalesce().  That may
be an appropriate name.

From the sqlite documentation:

coalesce(X,Y,...)  Return a copy of the first non-NULL argument. If all
arguments are NULL then NULL is returned. There must be
at least 2 arguments.

And from the postgres documentation:

COALESCE(value [, ...])

The COALESCE function returns the first of its arguments that is not
null. Null is returned only if all arguments are null. This is often
useful to substitute a default value for null values when data is
retrieved for display, for example:

SELECT COALESCE(description, short_description, '(none)') ...

Like a CASE expression, COALESCE will not evaluate arguments that are not
needed to determine the result; that is, arguments to the right of the
first non-null argument are not evaluated.

The coalesce() function is from the ANSI/ISO SQL:1999 standard, so its use has
been around for a while.

Derrell

Marcus Börger

22 years ago

Hello Christian,

Thursday, July 8, 2004, 5:13:36 PM, you wrote:

> Jason Garber wrote:
>> What we basically settled on was to use this syntax (as a new language
>> construct):
>> $x = ifsetor(mixed variable, mixed default);

> Before it gets forgotten: I still think that
> $x = ifsetor(mixed var, mixed var [, ...]);
> with expressions in all parts is the way to go.

As i wrote before several times before to me this seems impossible. But
maybe someone can come up with a working patch?

Best regards,
Marcus                            mailto:helly@php.net

Christian Schneider

22 years ago

Marcus Boerger wrote:

> As i wrote before several times before to me this seems impossible. But
> maybe someone can come up with a working patch?

I'll have a look at it as soon as I find time (not this week anyway).

What I'm looking for is the equivalent of
coalesce($a, $b) == @($a ? $a : b)
or
coalesce($a, $b, $c) == @($a ? $a : ($b ? $b : $c))
e.g. a silenced version of a multi-value ?: operator.

Or to go back to my initial example
coalesce($_REQUEST['x'], $db->get('x'), 'default_x') ==
@($_REQUEST['x'] ? $_REQUEST['x'] : ($_x = $db->get('x') ? $_x :
'default_x'))

This is definitely not impossible and I consider the silencing of the
whole function call inside the coalesce() construct a non-problem. (If
someone wanted to do a version where stuff inside function calls aren't
silenced any more then one'd need to track the nesting level. I myself
wouldn't care.)

- Chris