Sounds good. CoffeeScript (a lightweight language with JS semantics that
compiles to JS) has a existential operator, "?", and this looks similar and
would be very nice. It's not the same thing, of course. It also reminds me
of JavaScript's || behaviour.

On Wed, Jul 18, 2012 at 4:20 PM, Anthony Ferrara <ircmaxell@gmail.com

wrote:

Does this seem like a possible improvement we can work on? Anyone

interested in championing the change?

I like it in principle. My only concern is why wasn't it done this way
in the first place... Is there a reason?

I don't recall correctly, there was a thread on this by David Coalier some
time ago, but it went completely off course and i remember BC breaks were
part of the reason. I think we have a good plan for BC breaks now, so why
not rethink this.

Anthony

--
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br

It changes the semantics. If the variable is set to a falsey value and ?:
uses an implicit isset, the value of the expression will be the falsey
value.

$config['width'] = ''
$width = $config['width'] ?: 300

$width == ''

If !empty were used instead of isset, you could preserve semantics ($a ?:
dflt = !empty($a) ? $a : dflt).

Since this has been discussed before, here's a previous solution with zero
of those problems:

// A new operator.
$width = $config['width'] ?? 300;

// Actual behavior of the operator in pseudo code:
$width = isset($config['width']) ? $config['width'] : 300;

Why wasn't it implemented? No reason, it just wasn't. But people keep asking
about it, so it's only a matter of time.

Stan

On Wed, Jul 18, 2012 at 12:21 PM, Galen Wright-Watson ww.galen@gmail.comwrote:

On Wed, Jul 18, 2012 at 7:20 AM, Anthony Ferrara ircmaxell@gmail.comwrote:

On Wed, Jul 18, 2012 at 10:15 AM, Rafael Dohms <listas@rafaeldohms.com.br

wrote:

[...]

This is basically because the ternary operator does not do a internal
implicit isset, only an empty.

It does not do an empty. Empty would avoid notices as well. All it does is
an implicit bool cast...

Does this seem like a possible improvement we can work on? Anyone
interested in championing the change?

I like it in principle. My only concern is why wasn't it done this way
in
the first place... Is there a reason?

It changes the semantics. If the variable is set to a falsey value and ?:
uses an implicit isset, the value of the expression will be the falsey
value.

$config['width'] = ''
$width = $config['width'] ?: 300
# $width == ''

If !empty were used instead of isset, you could preserve semantics ($a ?:
dflt = !empty($a) ? $a : dflt).

However, this would break if someone were to use an explicit isset, so ?:
could only use an implicit !empty if the expression isn't an isset
expression (which starts to get messy, grammar-wise).

Looking over the previous discussion, people objected to altering the
behavior of ?: precisely because it currently generates notices, which they
desire.

The following use-cases were put forward as commonly occurring and verbose
enough to desire syntactic sugar:

1. isset($arr['key']) ? $arr['key'] : dflt
2. ! empty($arr['key']) ? $arr['key'] : dflt
3. ! is_null($arr['key']) ? $arr['key'] : dflt (used instead of isset
   version; both wouldn't appear in same code base)
4. $arr['key'] = isset($arr['key']) ? $arr['key'] : dflt
5. isset($arr['key']) ? strtoupper($arr['key']) : dflt

The following new operators were suggested:

1. new ternary based on isset (e.g. "$a ?? strtoupper($a) : 'DFLT'" with
   implicit isset)
2. new shortcut ternary based on isset
3. new shortcut ternary based on !empty (objection: not as useful as
   isset, since !empty is equivalent to !! but with notice suppression)
4. new shortcut ternary based on !== null or ! is_null
5. new shortcut ternary that only works on arrays and is based
   on array_key_exists
6. indexing operator that suppress undefined index notices
7. variable access that suppresses undefined variable notices
8. assign-if-not-set operator (like ||= in Javascript)

Some objections to the above:

1. (new ternary) ?

2. (isset) Some developers always set variables and never want undefined
   notice suppression (the "never-unset" style), which isset will do. However,
   this isn't as common a style.

3. (!empty) Not as useful as isset, since !empty is equivalent to !! but
   with notice suppression. Also, !empty($a)?$a:dflt isn't used as much as
   isset($a)?$a:dflt.

4. (!== null / ! is_null) Not as useful as isset, since it doesn't
   suppress notices, so isn't a replacement for the isset($a)?$a:dflt pattern.
   However, it can be used in combination with 6 for the isset-based ternary
   for arrays (e.g. "$arr?['key'] ?: 'dflt'").

5. (array_key_exists) Conceptually, anything unset has a null value, and
   should thus be equivalent in value to something set to NULL.
   array_key_exists distinguishes between unset and set to NULL, which
   won't always match how some want to use the shortcut ternary. Thus, not as
   useful as is_null.

6. (indexing w/o notices) ?

7. (variable access) Probably do more harm than good. It's easy to
   ensure a variable is set.

8. (assign-if-not-set) For arrays, there's the alternative:

   $arr += Array('key' => 'value');

This can also be used for a "never-unset" style to set defaults for an
array, which goes with the "! is_null($a) ? $a : dflt" pattern.

Various syntax proposals:

1. "$a ?? $b : dflt" as a ternary, with shortcutting behavior.
2. "$a ?? dflt" as a shortcut ternary
3. "$a ?! dflt" as a shortcut ternary based on !empty (could be added
   along with "??"; objection is that it could ambiguate PHP's syntax,
   conflicting with the not operator)
4. "$a $: dflt" as a shortcut ternary
5. "$arr?['key']" to suppress undefined index notices
6. "$arr@['key']" to suppress undefined index notices
7. "$?var" to suppress undefined variable notices
8. "$a ??= dflt" as an assign-if-not-set operator (goes along with "??")
9. "$a !?= dflt" as an assign-if-not-set operator ("!" suggests not-set)
10. "$a $:= dflt" as an assign-if-not-set operator (goes along with "$:")

?? / isset vs ?? / is_null

Of the various proposals, "??" (with semantics of "isset($a) ? $a : dflt")
already has a precedence: in C# as the null-coalescing operator. While PHP
doesn't have non-nullable types (hence "??" isn't a necessity), using ?? is
perhaps the least surprising option, and (including "??=") would cover
use-cases 1 and 4. On the other hand, PHP's "??" wouldn't be the same as
C#, since C# requires that variables be declared. Arguably, having "??"
equivalent to "!is_null($a) ? $a : dflt" is closer to C# semantics. Also,
use-cases 2 and 3 would be left out, whereas operator proposals 4 (?? /
is_null), 6 (?[]) and 8 (??= / is_null) together cover use-cases 1, 3 and

4. Back on the first hand, use-cases 2 and 3 are less common and this is
   (after all) merely syntactic sugar, which should be targeting the common
   cases.

??: vs ??

The ternary "??:" (whether based on isset or is_null) can also cover
use-case 5, but isn't so good for case 4 ("??:=" would be ugly). One one
hand, the short-cut "??:" may be surprising to developers familiar with
C#'s "??:". On the other, PHP ain't C#, and documentation can cover "??:".
Besides, "??" isn't the only null-coalescing operator out there, so why
should C# be given special consideration? Less rhetorically, would
supporting both "??" and "??:", with "$a ??: dflt" equivalent to "$a ?? dflt",
be undesirable?

Personally, I support syntaxes 8. ??= with either 1. ??: / isset or
(1. ??:/ is_null and 5.
?[]).

I think that you can compare the situation to the short if syntax ($a > $b
? $c : $d)

Not sure I understand... that is the situation under discussion,
no?

$a > $b ? ...

and

$a ? ...

both use the ternary operator.

You do raise (maybe on purpose, not totally clear what you were
getting at) the question of whether a more complex (expr1) in one of
these theoretical ternarys w/implicit isset, however it is
implemented, would apply the isset to any variable in (expr1)? That
is, if $a or $b do not exist, does

$a > $b ?? ...

return an error? What if both do not exist?

I think the conclusion (as reached by other people) is that the
operator needs to apply to each individual variable, not to a
multi-step deal like the ternary where there are more cases to
consider.

-- S.

2012/7/24 Yahav Gindi Bar g.b.yahav@gmail.com:

I don't think global operators is good idea since it can make a script very complex and you'll have to learn many operators in case the one who wrote it decided to make it "operator driven"

On the other hand: If those operators aren't global, then they are
local. I wouldn't like that much more, because inside "your project"
you will then never know, if and how an operator is currently working.
Much more confusion.

But I wouldn't like to see this operator-stuff using in a "normal"
context, in "normal" PHP-scripts. (What's normal?)

I see those operators in a very limited context, e.g. when you create
output (use PHP as template-engine), then they could be extremly
helpful. Always and alyways repeating things, which can't be made
shorter. For example checking the rights of a user:

set_operator_handler('r', function ($user, $current) {
....
if (!$userrRights->userHasRights($username, $current)) {
throw userRightsException(....)
}
}

and in the code:

try {
$user ?r: $current;
} catch
....

Ugly? Yes!!! Very! But that's wanted, because - as said - in very
special context. [But really? You can read the code as: "Has the user
the rights for current?"]

In the end this is a design-decision. I wouldn't recomend this for the
normal work (as shown above) and I think the said should be part of
the documentation - if it is really implemented. But I think in some
very special contexts this could be really helpful.

Yeah, that's a design decision, but its important because that's one of the PHP greatest things - the code is very nice and readable, and it's kind of sad to ruin it...

I didn't thought about template engines - I agree, it'll be great there, but does a language syntax need to be defined only for a specific cases like template engine?

However, if we're talking about operators, I do think that adding operator override option (for the regular operators, such as +, -, * etc.) will be great for OOP - but that's a different topic.

Existing operators shouldn't be changeable. My suggestion is the
"PHP-way" of operator driven development for a very special problem,
which is making very repeating but complex things very short, nothing
else. :)

Or in other words: In detail it's great, but in general it's a very
bad idea. :) That's just wanted and if you think you must use it, then
you should have a good reason.

--
Alex Aulbach

If the programmers will follow your guidelines and use this operators only for some unique and rare cases - I strongly support that idea, but I'm afraid from programmers who'll make their program full of operators which makes it unreadable by other programers...

I think that operators overriding should be implemented in a class scope (only for object with object interaction, such as (merge operation): $mergedMember = $member1 + $member2; or for roles permission concat - $memberRule = $adminRule - $editorRule)
But that's a different topic from the suggested feature...