[Proposal] Modification to ?: functionality

11 years ago by Chris London — view source

unread

I find in a lot of my code I have ternaries that set default values. I
also find that I can't use the ?: syntax for one reason and one reason
only. It throws a notice if the value isn't set.

I believe these two statements are functionally equivalent:

$foo = $foo ? $foo : 'default';

$foo = $foo ?: 'default';

I would like to change it so it also checks for isset() so I propose the
following would be functionally equivalent:

$foo = isset($foo) && $foo ? $foo : 'default';

$foo = $foo ?: 'default';

Random addition: what if we also allowed the following shorthand?

$foo ?= 'default';

or possibly:

$foo ?:= 'default';

Thanks everyone,
Chris

11 years ago by Etienne Kneuss — view source

unread

Hi Chris,

I find in a lot of my code I have ternaries that set default values. I
also find that I can't use the ?: syntax for one reason and one reason
only. It throws a notice if the value isn't set.

I believe these two statements are functionally equivalent:

$foo = $foo ? $foo : 'default';

$foo = $foo ?: 'default';

I would like to change it so it also checks for isset() so I propose the
following would be functionally equivalent:

$foo = isset($foo) && $foo ? $foo : 'default';

$foo = $foo ?: 'default';

I would be happy to see a patch for that, last time I checked it was hard
to make the grammar happy with this change.

Note that it's not necessarily a variable. It should have no impact on:

$foo = gee() ?: "default";

Random addition: what if we also allowed the following shorthand?

$foo ?= 'default';

or possibly:

$foo ?:= 'default';

Thanks everyone,
Chris

--
Etienne Kneuss
http://www.colder.ch

11 years ago by Mats Lindh — view source

unread

I believe these two statements are functionally equivalent:

$foo = $foo ? $foo : 'default';

$foo = $foo ?: 'default';

They are.

I would like to change it so it also checks for isset() so I propose the

following would be functionally equivalent:

$foo = isset($foo) && $foo ? $foo : 'default';

$foo = $foo ?: 'default';

The would break the assumption that a reference to an uninitialized value
would generate a notice, unless explicitly handled in the logic.

While I also would like to have something similar to ?: to handle default
values for array keys, etc., this would change a fundamental assumption
that as been in place for many years now. I'm not sure if that's a BC break
that would be acceptable this late. An alternative operator may be more
suitable.

The change proposed has also been discussed several times since the
implementation of ?:. See the ifsetor-RFC:

https://wiki.php.net/rfc/ifsetor

It also contains links to the discussion around the feature back then.

--mats

11 years ago by Jannik Zschiesche — view source

unread

Hi,

Am Dienstag, 26. November 2013 um 16:15 schrieb Mats Lindh:

following would be functionally equivalent:

$foo = isset($foo) && $foo ? $foo : 'default';

$foo = $foo ?: 'default';

The would break the assumption that a reference to an uninitialized value
would generate a notice, unless explicitly handled in the logic.

While I also would like to have something similar to ?: to handle default
values for array keys, etc., this would change a fundamental assumption
that as been in place for many years now. I'm not sure if that's a BC break
that would be acceptable this late. An alternative operator may be more
suitable.

Since the discussion about it is quite vivid at the moment:
wouldn’t this be a nice candidate for one of the changes in the next major version?

--
Cheers Jannik

11 years ago by Peter Cowburn — view source

unread

Hi,

Am Dienstag, 26. November 2013 um 16:15 schrieb Mats Lindh:

On Tue, Nov 26, 2013 at 3:43 PM, Chris London <me@chrislondon.co(mailto:
me@chrislondon.co)> wrote:

following would be functionally equivalent:

$foo = isset($foo) && $foo ? $foo : 'default';

$foo = $foo ?: 'default';

The would break the assumption that a reference to an uninitialized value
would generate a notice, unless explicitly handled in the logic.

While I also would like to have something similar to ?: to handle default
values for array keys, etc., this would change a fundamental assumption
that as been in place for many years now. I'm not sure if that's a BC
break
that would be acceptable this late. An alternative operator may be more
suitable.

Since the discussion about it is quite vivid at the moment:
wouldn’t this be a nice candidate for one of the changes in the next major
version?

What are your (everyone's) thoughts on the following, given the current
topic of discussion?

$foo = $fo ?: 'default'; // see what I did there?

I'm not sure changing the ?: to always use isset() is necessarily a good
thing given my propensity for tiping mystakes.

--
Cheers Jannik

11 years ago by Bryan C. Geraghty — view source

unread

-----Original Message-----
From: Peter Cowburn [mailto:petercowburn@gmail.com]
Sent: Tuesday, November 26, 2013 10:50 AM
To: Jannik Zschiesche
Cc: Mats Lindh; Chris London; internals@lists.php.net
Subject: Re: [PHP-DEV] [Proposal] Modification to ?: functionality

What are your (everyone's) thoughts on the following, given the current
topic of discussion?

$foo = $fo ?: 'default'; // see what I did there?

I'm not sure changing the ?: to always use isset() is necessarily a good
thing given my propensity for tiping mystakes.

I don't like this change for exactly the reason Peter pointed out.

I also thought about the fact that I often write a utility function to
provide this functionality in my own code. The difference there is that I
can remove the check and get the notices when debugging something. If this
change were part of the language, that wouldn't be possible.

Bryan

11 years ago by Chris London — view source

unread

I believe these two statements are functionally equivalent:

$foo = $foo ? $foo : 'default';

$foo = $foo ?: 'default';

They are.

I would like to change it so it also checks for isset() so I propose the

following would be functionally equivalent:

$foo = isset($foo) && $foo ? $foo : 'default';

$foo = $foo ?: 'default';

The would break the assumption that a reference to an uninitialized value
would generate a notice, unless explicitly handled in the logic.

While I also would like to have something similar to ?: to handle default
values for array keys, etc., this would change a fundamental assumption
that as been in place for many years now. I'm not sure if that's a BC break
that would be acceptable this late. An alternative operator may be more
suitable.

What do you think about using:

$foo = $foo @: 'default';

and possibly

$foo @= 'default';

The change proposed has also been discussed several times since the
implementation of ?:. See the ifsetor-RFC:

https://wiki.php.net/rfc/ifsetor

It also contains links to the discussion around the feature back then.

--mats

11 years ago by Paul Dragoonis — view source

unread

I believe these two statements are functionally equivalent:

$foo = $foo ? $foo : 'default';

$foo = $foo ?: 'default';

They are.

I would like to change it so it also checks for isset() so I propose the

following would be functionally equivalent:

$foo = isset($foo) && $foo ? $foo : 'default';

$foo = $foo ?: 'default';

We can't change the behaviour of ?: that ship has already sailed, we'll
just be hurting existing codebases on upgrading and more user education is
required to understand non-visual changes in syntax like this, lets try to
learn from our mistakes by not changing 'behaviour' anymore.

An alternative syntax that is similar and not ugly would be good since the
?: behaviour was broken from the start since you still need to run isset()
before running ?: which was the problem we tried to solve in the first
place but it just didn't happen.

I don't like the @ symbol it's too different from what's already there on
the ternary logic.

Proposal: $foo = $arr['value'] ?:: "";

Thoughts?

The would break the assumption that a reference to an uninitialized value
would generate a notice, unless explicitly handled in the logic.

While I also would like to have something similar to ?: to handle default
values for array keys, etc., this would change a fundamental assumption
that as been in place for many years now. I'm not sure if that's a BC
break
that would be acceptable this late. An alternative operator may be more
suitable.

What do you think about using:

$foo = $foo @: 'default';

and possibly

$foo @= 'default';

The change proposed has also been discussed several times since the
implementation of ?:. See the ifsetor-RFC:

https://wiki.php.net/rfc/ifsetor

It also contains links to the discussion around the feature back then.

--mats

11 years ago by Etienne Kneuss — view source

unread

On Tue, Nov 26, 2013 at 8:15 AM, Mats Lindh mats.lindh@gmail.com
wrote:

On Tue, Nov 26, 2013 at 3:43 PM, Chris London me@chrislondon.co
wrote:

I believe these two statements are functionally equivalent:

$foo = $foo ? $foo : 'default';

$foo = $foo ?: 'default';

They are.

I would like to change it so it also checks for isset() so I propose
the

following would be functionally equivalent:

$foo = isset($foo) && $foo ? $foo : 'default';

$foo = $foo ?: 'default';

We can't change the behaviour of ?: that ship has already sailed, we'll
just be hurting existing codebases on upgrading and more user education is
required to understand non-visual changes in syntax like this, lets try to
learn from our mistakes by not changing 'behaviour' anymore.

I disagree, I think removing a case for a Notice is the kind of BC break we
can allow, especially in major versions.

We should aim at making the language easier to use for day to day cases,
and I think this change goes in that direction.

An alternative syntax that is similar and not ugly would be good since the
?: behaviour was broken from the start since you still need to run isset()
before running ?: which was the problem we tried to solve in the first
place but it just didn't happen.

I don't like the @ symbol it's too different from what's already there on
the ternary logic.

Proposal: $foo = $arr['value'] ?:: "";

Thoughts?

The would break the assumption that a reference to an uninitialized
value
would generate a notice, unless explicitly handled in the logic.

While I also would like to have something similar to ?: to handle
default
values for array keys, etc., this would change a fundamental assumption
that as been in place for many years now. I'm not sure if that's a BC
break
that would be acceptable this late. An alternative operator may be more
suitable.

What do you think about using:

$foo = $foo @: 'default';

and possibly

$foo @= 'default';

The change proposed has also been discussed several times since the
implementation of ?:. See the ifsetor-RFC:

https://wiki.php.net/rfc/ifsetor

It also contains links to the discussion around the feature back then.

--mats

--
Etienne Kneuss
http://www.colder.ch

11 years ago by Chris London — view source

unread

On Tue, Nov 26, 2013 at 10:41 AM, Paul Dragoonis dragoonis@gmail.comwrote:

On Tue, Nov 26, 2013 at 3:43 PM, Chris London me@chrislondon.co
wrote:

I believe these two statements are functionally equivalent:

$foo = $foo ? $foo : 'default';

$foo = $foo ?: 'default';

They are.

I would like to change it so it also checks for isset() so I propose the

following would be functionally equivalent:

$foo = isset($foo) && $foo ? $foo : 'default';

$foo = $foo ?: 'default';

We can't change the behaviour of ?: that ship has already sailed, we'll
just be hurting existing codebases on upgrading and more user education is
required to understand non-visual changes in syntax like this, lets try to
learn from our mistakes by not changing 'behaviour' anymore.

An alternative syntax that is similar and not ugly would be good since the
?: behaviour was broken from the start since you still need to run isset()
before running ?: which was the problem we tried to solve in the first
place but it just didn't happen.

I don't like the @ symbol it's too different from what's already there on
the ternary logic.

My reason for the @ symbol was that it's already used to suppress errors so
to me it seems like it could be interpreted as a suppressed ternary but I'm
open to other suggestions.

Proposal: $foo = $arr['value'] ?:: "";

I'd be fine with this choice.

Thoughts?

The would break the assumption that a reference to an uninitialized
value
would generate a notice, unless explicitly handled in the logic.

While I also would like to have something similar to ?: to handle
default
values for array keys, etc., this would change a fundamental assumption
that as been in place for many years now. I'm not sure if that's a BC
break
that would be acceptable this late. An alternative operator may be more
suitable.

What do you think about using:

$foo = $foo @: 'default';

and possibly

$foo @= 'default';

The change proposed has also been discussed several times since the
implementation of ?:. See the ifsetor-RFC:

https://wiki.php.net/rfc/ifsetor

It also contains links to the discussion around the feature back then.

--mats

11 years ago by Etienne Kneuss — view source

unread

On Tue, Nov 26, 2013 at 10:41 AM, Paul Dragoonis <dragoonis@gmail.com

wrote:

On Tue, Nov 26, 2013 at 8:15 AM, Mats Lindh mats.lindh@gmail.com
wrote:

On Tue, Nov 26, 2013 at 3:43 PM, Chris London me@chrislondon.co
wrote:

I believe these two statements are functionally equivalent:

$foo = $foo ? $foo : 'default';

$foo = $foo ?: 'default';

They are.

I would like to change it so it also checks for isset() so I propose
the

following would be functionally equivalent:

$foo = isset($foo) && $foo ? $foo : 'default';

$foo = $foo ?: 'default';

We can't change the behaviour of ?: that ship has already sailed, we'll
just be hurting existing codebases on upgrading and more user education
is
required to understand non-visual changes in syntax like this, lets try
to
learn from our mistakes by not changing 'behaviour' anymore.

An alternative syntax that is similar and not ugly would be good since
the
?: behaviour was broken from the start since you still need to run
isset()
before running ?: which was the problem we tried to solve in the first
place but it just didn't happen.

I don't like the @ symbol it's too different from what's already there on
the ternary logic.

My reason for the @ symbol was that it's already used to suppress errors so
to me it seems like it could be interpreted as a suppressed ternary but I'm
open to other suggestions.

Proposal: $foo = $arr['value'] ?:: "";

I'd be fine with this choice.

I don't see any value in adding yet another operator for this, we already
support this through:

$foo = @$arr['value'] ?: "";

Thoughts?

The would break the assumption that a reference to an uninitialized
value
would generate a notice, unless explicitly handled in the logic.

While I also would like to have something similar to ?: to handle
default
values for array keys, etc., this would change a fundamental
assumption
that as been in place for many years now. I'm not sure if that's a BC
break
that would be acceptable this late. An alternative operator may be
more
suitable.

What do you think about using:

$foo = $foo @: 'default';

and possibly

$foo @= 'default';

The change proposed has also been discussed several times since the
implementation of ?:. See the ifsetor-RFC:

https://wiki.php.net/rfc/ifsetor

It also contains links to the discussion around the feature back then.

--mats

--
Etienne Kneuss
http://www.colder.ch

11 years ago by Paul Dragoonis — view source

unread

On Tue, Nov 26, 2013 at 10:41 AM, Paul Dragoonis <dragoonis@gmail.com

wrote:

On Tue, Nov 26, 2013 at 4:58 PM, Chris London me@chrislondon.co
wrote:

On Tue, Nov 26, 2013 at 8:15 AM, Mats Lindh mats.lindh@gmail.com
wrote:

On Tue, Nov 26, 2013 at 3:43 PM, Chris London me@chrislondon.co
wrote:

I believe these two statements are functionally equivalent:

$foo = $foo ? $foo : 'default';

$foo = $foo ?: 'default';

They are.

I would like to change it so it also checks for isset() so I propose
the

following would be functionally equivalent:

$foo = isset($foo) && $foo ? $foo : 'default';

$foo = $foo ?: 'default';

We can't change the behaviour of ?: that ship has already sailed, we'll
just be hurting existing codebases on upgrading and more user education
is
required to understand non-visual changes in syntax like this, lets try
to
learn from our mistakes by not changing 'behaviour' anymore.

An alternative syntax that is similar and not ugly would be good since
the
?: behaviour was broken from the start since you still need to run
isset()
before running ?: which was the problem we tried to solve in the first
place but it just didn't happen.

I don't like the @ symbol it's too different from what's already there
on
the ternary logic.

My reason for the @ symbol was that it's already used to suppress errors
so
to me it seems like it could be interpreted as a suppressed ternary but
I'm
open to other suggestions.

Proposal: $foo = $arr['value'] ?:: "";

I'd be fine with this choice.

I don't see any value in adding yet another operator for this, we already
support this through:

$foo = @$arr['value'] ?: "";

Constant intentional error suppression isn't really what we need since the
error still happens it just doesn't go through logging and such, whereas
from my limited understanding isset() will not trigger any errors to happen
at all, so there is a difference here for sure.

Thoughts?

The would break the assumption that a reference to an uninitialized
value
would generate a notice, unless explicitly handled in the logic.

While I also would like to have something similar to ?: to handle
default
values for array keys, etc., this would change a fundamental
assumption
that as been in place for many years now. I'm not sure if that's a BC
break
that would be acceptable this late. An alternative operator may be
more
suitable.

What do you think about using:

$foo = $foo @: 'default';

and possibly

$foo @= 'default';

The change proposed has also been discussed several times since the
implementation of ?:. See the ifsetor-RFC:

https://wiki.php.net/rfc/ifsetor

It also contains links to the discussion around the feature back
then.

--mats

--
Etienne Kneuss
http://www.colder.ch

11 years ago by Philip Sturgeon — view source

unread

On Tue, Nov 26, 2013 at 10:41 AM, Paul Dragoonis <dragoonis@gmail.com

wrote:

On Tue, Nov 26, 2013 at 8:15 AM, Mats Lindh mats.lindh@gmail.com
wrote:

On Tue, Nov 26, 2013 at 3:43 PM, Chris London me@chrislondon.co
wrote:

I believe these two statements are functionally equivalent:

$foo = $foo ? $foo : 'default';

$foo = $foo ?: 'default';

They are.

I would like to change it so it also checks for isset() so I propose
the

following would be functionally equivalent:

$foo = isset($foo) && $foo ? $foo : 'default';

$foo = $foo ?: 'default';

We can't change the behaviour of ?: that ship has already sailed, we'll
just be hurting existing codebases on upgrading and more user education
is
required to understand non-visual changes in syntax like this, lets try
to
learn from our mistakes by not changing 'behaviour' anymore.

An alternative syntax that is similar and not ugly would be good since
the
?: behaviour was broken from the start since you still need to run
isset()
before running ?: which was the problem we tried to solve in the first
place but it just didn't happen.

I don't like the @ symbol it's too different from what's already there on
the ternary logic.

My reason for the @ symbol was that it's already used to suppress errors so
to me it seems like it could be interpreted as a suppressed ternary but I'm
open to other suggestions.

Proposal: $foo = $arr['value'] ?:: "";

I'd be fine with this choice.

I don't see any value in adding yet another operator for this, we already
support this through:

$foo = @$arr['value'] ?: "";

--
Etienne Kneuss
http://www.colder.ch

We probably shouldn't pretend that using @ to help set default values
is a good idea.

11 years ago by John Bafford — view source

unread

I believe these two statements are functionally equivalent:

$foo = $foo ? $foo : 'default';
$foo = $foo ?: 'default';

They are.

I would like to change it so it also checks for isset() so I propose the

following would be functionally equivalent:

$foo = isset($foo) && $foo ? $foo : 'default';
$foo = $foo ?: 'default';

We can't change the behaviour of ?: that ship has already sailed, we'll
just be hurting existing codebases on upgrading and more user education is
required to understand non-visual changes in syntax like this, lets try to
learn from our mistakes by not changing 'behaviour' anymore.

An alternative syntax that is similar and not ugly would be good since the
?: behaviour was broken from the start since you still need to run isset()
before running ?: which was the problem we tried to solve in the first
place but it just didn't happen.

I don't like the @ symbol it's too different from what's already there on
the ternary logic.

Proposal: $foo = $arr['value'] ?:: "";

Thoughts?

What if it was:

$foo ?? $trueVal : $falseVal;

with the shortened form being:

$foo ??: $falseVal;

This would make the isset($foo) && $foo functionality available for the three operand version of ??:, and by making the ? the operator that's doubled in that case would make it more clear when reading as to what's going on (and maybe make it easier to parse?).

-John

The would break the assumption that a reference to an uninitialized value
would generate a notice, unless explicitly handled in the logic.

While I also would like to have something similar to ?: to handle default
values for array keys, etc., this would change a fundamental assumption
that as been in place for many years now. I'm not sure if that's a BC
break
that would be acceptable this late. An alternative operator may be more
suitable.

What do you think about using:

$foo = $foo @: 'default';

and possibly

$foo @= 'default';

The change proposed has also been discussed several times since the
implementation of ?:. See the ifsetor-RFC:

https://wiki.php.net/rfc/ifsetor

It also contains links to the discussion around the feature back then.

--mats

11 years ago by Philip Sturgeon — view source

unread

I believe these two statements are functionally equivalent:

$foo = $foo ? $foo : 'default';

$foo = $foo ?: 'default';

They are.

I would like to change it so it also checks for isset() so I propose the

following would be functionally equivalent:

$foo = isset($foo) && $foo ? $foo : 'default';

$foo = $foo ?: 'default';

We can't change the behaviour of ?: that ship has already sailed, we'll
just be hurting existing codebases on upgrading and more user education is
required to understand non-visual changes in syntax like this, lets try to
learn from our mistakes by not changing 'behaviour' anymore.

An alternative syntax that is similar and not ugly would be good since the
?: behaviour was broken from the start since you still need to run isset()
before running ?: which was the problem we tried to solve in the first
place but it just didn't happen.

I don't like the @ symbol it's too different from what's already there on
the ternary logic.

Proposal: $foo = $arr['value'] ?:: "";

Thoughts?

The would break the assumption that a reference to an uninitialized value
would generate a notice, unless explicitly handled in the logic.

While I also would like to have something similar to ?: to handle default
values for array keys, etc., this would change a fundamental assumption
that as been in place for many years now. I'm not sure if that's a BC
break
that would be acceptable this late. An alternative operator may be more
suitable.

What do you think about using:

$foo = $foo @: 'default';

and possibly

$foo @= 'default';

The change proposed has also been discussed several times since the
implementation of ?:. See the ifsetor-RFC:

https://wiki.php.net/rfc/ifsetor

It also contains links to the discussion around the feature back then.

--mats

This seems like a cracking time to suggest:

$x ||= $y;

The difference? Anything left of the ? SHOULD fail if it is not set,
because you are using it in a condition which is dangerous and odd for
other types of condition, but adding in this new syntax (similar to
Ruby) would essentially evaluate to this:

empty($x) ? $y : $x;

This gives keeps the behavior of ternary operators working in the same
way, but adds what we want: the ability to nicely set defaults for
variables and array keys that may not be set.

11 years ago by Etienne Kneuss — view source

unread

On Tue, Nov 26, 2013 at 6:57 PM, Philip Sturgeon pjsturgeon@gmail.comwrote:

On Tue, Nov 26, 2013 at 12:41 PM, Paul Dragoonis dragoonis@gmail.com
wrote:

On Tue, Nov 26, 2013 at 8:15 AM, Mats Lindh mats.lindh@gmail.com
wrote:

On Tue, Nov 26, 2013 at 3:43 PM, Chris London me@chrislondon.co
wrote:

I believe these two statements are functionally equivalent:

$foo = $foo ? $foo : 'default';

$foo = $foo ?: 'default';

They are.

I would like to change it so it also checks for isset() so I propose
the

following would be functionally equivalent:

$foo = isset($foo) && $foo ? $foo : 'default';

$foo = $foo ?: 'default';

We can't change the behaviour of ?: that ship has already sailed, we'll
just be hurting existing codebases on upgrading and more user education
is
required to understand non-visual changes in syntax like this, lets try
to
learn from our mistakes by not changing 'behaviour' anymore.

An alternative syntax that is similar and not ugly would be good since
the
?: behaviour was broken from the start since you still need to run
isset()
before running ?: which was the problem we tried to solve in the first
place but it just didn't happen.

I don't like the @ symbol it's too different from what's already there on
the ternary logic.

Proposal: $foo = $arr['value'] ?:: "";

Thoughts?

The would break the assumption that a reference to an uninitialized
value
would generate a notice, unless explicitly handled in the logic.

While I also would like to have something similar to ?: to handle
default
values for array keys, etc., this would change a fundamental
assumption
that as been in place for many years now. I'm not sure if that's a BC
break
that would be acceptable this late. An alternative operator may be
more
suitable.

What do you think about using:

$foo = $foo @: 'default';

and possibly

$foo @= 'default';

The change proposed has also been discussed several times since the
implementation of ?:. See the ifsetor-RFC:

https://wiki.php.net/rfc/ifsetor

It also contains links to the discussion around the feature back then.

--mats

This seems like a cracking time to suggest:

$x ||= $y;

The difference? Anything left of the ? SHOULD fail if it is not set,
because you are using it in a condition which is dangerous and odd for
other types of condition, but adding in this new syntax (similar to
Ruby) would essentially evaluate to this:

empty($x) ? $y : $x;

This gives keeps the behavior of ternary operators working in the same
way, but adds what we want: the ability to nicely set defaults for
variables and array keys that may not be set.

To me this reads as $x = $x || $y like all the <OP>= binary operators. So
it would definitely feel weird to use that syntax for something else...

--

--
Etienne Kneuss
http://www.colder.ch

11 years ago by Chris London — view source

unread

On Tue, Nov 26, 2013 at 6:57 PM, Philip Sturgeon pjsturgeon@gmail.comwrote:

On Tue, Nov 26, 2013 at 12:41 PM, Paul Dragoonis dragoonis@gmail.com
wrote:

On Tue, Nov 26, 2013 at 4:58 PM, Chris London me@chrislondon.co
wrote:

On Tue, Nov 26, 2013 at 8:15 AM, Mats Lindh mats.lindh@gmail.com
wrote:

On Tue, Nov 26, 2013 at 3:43 PM, Chris London me@chrislondon.co
wrote:

I believe these two statements are functionally equivalent:

$foo = $foo ? $foo : 'default';

$foo = $foo ?: 'default';

They are.

I would like to change it so it also checks for isset() so I propose
the

following would be functionally equivalent:

$foo = isset($foo) && $foo ? $foo : 'default';

$foo = $foo ?: 'default';

We can't change the behaviour of ?: that ship has already sailed, we'll
just be hurting existing codebases on upgrading and more user education
is
required to understand non-visual changes in syntax like this, lets try
to
learn from our mistakes by not changing 'behaviour' anymore.

An alternative syntax that is similar and not ugly would be good since
the
?: behaviour was broken from the start since you still need to run
isset()
before running ?: which was the problem we tried to solve in the first
place but it just didn't happen.

I don't like the @ symbol it's too different from what's already there
on
the ternary logic.

Proposal: $foo = $arr['value'] ?:: "";

Thoughts?

The would break the assumption that a reference to an uninitialized
value
would generate a notice, unless explicitly handled in the logic.

While I also would like to have something similar to ?: to handle
default
values for array keys, etc., this would change a fundamental
assumption
that as been in place for many years now. I'm not sure if that's a BC
break
that would be acceptable this late. An alternative operator may be
more
suitable.

What do you think about using:

$foo = $foo @: 'default';

and possibly

$foo @= 'default';

The change proposed has also been discussed several times since the
implementation of ?:. See the ifsetor-RFC:

https://wiki.php.net/rfc/ifsetor

It also contains links to the discussion around the feature back
then.

--mats

This seems like a cracking time to suggest:

$x ||= $y;

The difference? Anything left of the ? SHOULD fail if it is not set,
because you are using it in a condition which is dangerous and odd for
other types of condition, but adding in this new syntax (similar to
Ruby) would essentially evaluate to this:

empty($x) ? $y : $x;

This gives keeps the behavior of ternary operators working in the same
way, but adds what we want: the ability to nicely set defaults for
variables and array keys that may not be set.

To me this reads as $x = $x || $y like all the <OP>= binary operators. So
it would definitely feel weird to use that syntax for something else...

I really like that. I do stuff like that in Javascript right now.

--

--
Etienne Kneuss
http://www.colder.ch

11 years ago by Philip Sturgeon — view source

unread

On Tue, Nov 26, 2013 at 6:57 PM, Philip Sturgeon pjsturgeon@gmail.com
wrote:

On Tue, Nov 26, 2013 at 12:41 PM, Paul Dragoonis dragoonis@gmail.com
wrote:

On Tue, Nov 26, 2013 at 8:15 AM, Mats Lindh mats.lindh@gmail.com
wrote:

On Tue, Nov 26, 2013 at 3:43 PM, Chris London me@chrislondon.co
wrote:

I believe these two statements are functionally equivalent:

$foo = $foo ? $foo : 'default';

$foo = $foo ?: 'default';

They are.

I would like to change it so it also checks for isset() so I propose
the

following would be functionally equivalent:

$foo = isset($foo) && $foo ? $foo : 'default';

$foo = $foo ?: 'default';

We can't change the behaviour of ?: that ship has already sailed, we'll
just be hurting existing codebases on upgrading and more user education
is
required to understand non-visual changes in syntax like this, lets try
to
learn from our mistakes by not changing 'behaviour' anymore.

An alternative syntax that is similar and not ugly would be good since
the
?: behaviour was broken from the start since you still need to run
isset()
before running ?: which was the problem we tried to solve in the first
place but it just didn't happen.

I don't like the @ symbol it's too different from what's already there
on
the ternary logic.

Proposal: $foo = $arr['value'] ?:: "";

Thoughts?

The would break the assumption that a reference to an uninitialized
value
would generate a notice, unless explicitly handled in the logic.

While I also would like to have something similar to ?: to handle
default
values for array keys, etc., this would change a fundamental
assumption
that as been in place for many years now. I'm not sure if that's a BC
break
that would be acceptable this late. An alternative operator may be
more
suitable.

What do you think about using:

$foo = $foo @: 'default';

and possibly

$foo @= 'default';

The change proposed has also been discussed several times since the
implementation of ?:. See the ifsetor-RFC:

https://wiki.php.net/rfc/ifsetor

It also contains links to the discussion around the feature back
then.

--mats

This seems like a cracking time to suggest:

$x ||= $y;

The difference? Anything left of the ? SHOULD fail if it is not set,
because you are using it in a condition which is dangerous and odd for
other types of condition, but adding in this new syntax (similar to
Ruby) would essentially evaluate to this:

empty($x) ? $y : $x;

This gives keeps the behavior of ternary operators working in the same
way, but adds what we want: the ability to nicely set defaults for
variables and array keys that may not be set.

To me this reads as $x = $x || $y like all the <OP>= binary operators. So it
would definitely feel weird to use that syntax for something else...

--

--
Etienne Kneuss
http://www.colder.ch

It is not $x = $x || $y but $x || $x = $y.

http://www.rubyinside.com/what-rubys-double-pipe-or-equals-really-does-5488.html

Ternary is being used by us to set defaults, but it is not the only
use of ternary, so making it totally quieten potential warnings and
errors is a weird use of a ternary. It's one of those "we do it this
way because its all we have" options and going further down the road
of abusing ternaries for this functionality does not make the
situation more simple.

Currently:

 $foo = isset($foo) && $foo ? $foo : 'default';

Proposed change by OP (with BC break):

$foo = $foo ?: 'default';

New ternary suggested by others, with "error suppressing":

$foo = $foo ??: 'default';

People will try using that with all sorts of other operators involved.
What happens when you do $foo = $foo == 'bar' ??: 'default'; It gets
complicated.

$foo ||= 'default';

Pretty obvious what is happening. If foo is falsey it will use
'default'. We can wrap $foo in isset or empty and make it more
durable, which certainly would take care of the OP's concerns without
breaking the way ternaries currently work - which is not actually
broken just not very handy at setting defaults for non-existent
variables.

11 years ago by Jezz Goodwin — view source

unread

Hi,

Before mentioning anything about new syntax, I thought I'd point out that
this code is already possible for setting defaults:

(isset($foo)) ?: $foo = 'default';

isset($foo) ?: $foo = 'default';

(I personally prefer wrapping the condition within brackets)

Saying that, I do think a syntax for setting defaults which doesn't involve
typing the variable name twice would be nice.

My favourite one listed so far is:

$foo ?= 'default';

--
Jezz

On Tue, Nov 26, 2013 at 6:23 PM, Philip Sturgeon pjsturgeon@gmail.comwrote:

On Tue, Nov 26, 2013 at 6:57 PM, Philip Sturgeon pjsturgeon@gmail.com
wrote:

On Tue, Nov 26, 2013 at 12:41 PM, Paul Dragoonis dragoonis@gmail.com
wrote:

On Tue, Nov 26, 2013 at 4:58 PM, Chris London me@chrislondon.co
wrote:

On Tue, Nov 26, 2013 at 8:15 AM, Mats Lindh mats.lindh@gmail.com
wrote:

On Tue, Nov 26, 2013 at 3:43 PM, Chris London me@chrislondon.co
wrote:

I believe these two statements are functionally equivalent:

$foo = $foo ? $foo : 'default';

$foo = $foo ?: 'default';

They are.

I would like to change it so it also checks for isset() so I
propose
the

following would be functionally equivalent:

$foo = isset($foo) && $foo ? $foo : 'default';

$foo = $foo ?: 'default';

We can't change the behaviour of ?: that ship has already sailed,
we'll
just be hurting existing codebases on upgrading and more user
education
is
required to understand non-visual changes in syntax like this, lets
try
to
learn from our mistakes by not changing 'behaviour' anymore.

An alternative syntax that is similar and not ugly would be good since
the
?: behaviour was broken from the start since you still need to run
isset()
before running ?: which was the problem we tried to solve in the first
place but it just didn't happen.

I don't like the @ symbol it's too different from what's already there
on
the ternary logic.

Proposal: $foo = $arr['value'] ?:: "";

Thoughts?

The would break the assumption that a reference to an uninitialized
value
would generate a notice, unless explicitly handled in the logic.

While I also would like to have something similar to ?: to handle
default
values for array keys, etc., this would change a fundamental
assumption
that as been in place for many years now. I'm not sure if that's a
BC
break
that would be acceptable this late. An alternative operator may be
more
suitable.

What do you think about using:

$foo = $foo @: 'default';

and possibly

$foo @= 'default';

The change proposed has also been discussed several times since the
implementation of ?:. See the ifsetor-RFC:

https://wiki.php.net/rfc/ifsetor

It also contains links to the discussion around the feature back
then.

--mats

This seems like a cracking time to suggest:

$x ||= $y;

The difference? Anything left of the ? SHOULD fail if it is not set,
because you are using it in a condition which is dangerous and odd for
other types of condition, but adding in this new syntax (similar to
Ruby) would essentially evaluate to this:

empty($x) ? $y : $x;

This gives keeps the behavior of ternary operators working in the same
way, but adds what we want: the ability to nicely set defaults for
variables and array keys that may not be set.

To me this reads as $x = $x || $y like all the <OP>= binary operators.
So it
would definitely feel weird to use that syntax for something else...

--

--
Etienne Kneuss
http://www.colder.ch

It is not $x = $x || $y but $x || $x = $y.

http://www.rubyinside.com/what-rubys-double-pipe-or-equals-really-does-5488.html

Ternary is being used by us to set defaults, but it is not the only
use of ternary, so making it totally quieten potential warnings and
errors is a weird use of a ternary. It's one of those "we do it this
way because its all we have" options and going further down the road
of abusing ternaries for this functionality does not make the
situation more simple.

Currently:
 $foo = isset($foo) && $foo ? $foo : 'default';
Proposed change by OP (with BC break):
$foo = $foo ?: 'default';
New ternary suggested by others, with "error suppressing":
$foo = $foo ??: 'default';
People will try using that with all sorts of other operators involved.
What happens when you do $foo = $foo == 'bar' ??: 'default'; It gets
complicated.
$foo ||= 'default';
Pretty obvious what is happening. If foo is falsey it will use
'default'. We can wrap $foo in isset or empty and make it more
durable, which certainly would take care of the OP's concerns without
breaking the way ternaries currently work - which is not actually
broken just not very handy at setting defaults for non-existent
variables.

11 years ago by Pete Boere — view source

unread

My favourite one listed so far is:

$foo ?= 'default';

I'd second that.

11 years ago by keisial@gmail.com — view source

unread

My favourite one listed so far is:

$foo ?= 'default';
I'd second that.
+1

Bryan wrote:

I also thought about the fact that I often write a utility function to
provide this functionality in my own code. The difference there is that I
can remove the check and get the notices when debugging something. If this
change were part of the language, that wouldn't be possible.

Bryan
It would be easy for xdebug to provide a setting enabling the notice.

11 years ago by Peter Cowburn — view source

unread

Hi,

Before mentioning anything about new syntax, I thought I'd point out that
this code is already possible for setting defaults:

(isset($foo)) ?: $foo = 'default';

or

isset($foo) ?: $foo = 'default';

(I personally prefer wrapping the condition within brackets)

Saying that, I do think a syntax for setting defaults which doesn't involve
typing the variable name twice would be nice.

My favourite one listed so far is:

$foo ?= 'default';

I like that too.

Elaborating on that idea, here’s one idea from a while back, making much
wider use of a “?” operator… https://gist.github.com/salathe/3256826

--
Jezz

On Tue, Nov 26, 2013 at 6:23 PM, Philip Sturgeon <pjsturgeon@gmail.com

wrote:

On Tue, Nov 26, 2013 at 6:57 PM, Philip Sturgeon <pjsturgeon@gmail.com

wrote:

On Tue, Nov 26, 2013 at 12:41 PM, Paul Dragoonis <dragoonis@gmail.com

wrote:

On Tue, Nov 26, 2013 at 4:58 PM, Chris London me@chrislondon.co
wrote:

On Tue, Nov 26, 2013 at 8:15 AM, Mats Lindh mats.lindh@gmail.com
wrote:

On Tue, Nov 26, 2013 at 3:43 PM, Chris London <me@chrislondon.co

wrote:

I believe these two statements are functionally equivalent:

$foo = $foo ? $foo : 'default';

$foo = $foo ?: 'default';

They are.

I would like to change it so it also checks for isset() so I
propose
the

following would be functionally equivalent:

$foo = isset($foo) && $foo ? $foo : 'default';

$foo = $foo ?: 'default';

We can't change the behaviour of ?: that ship has already sailed,
we'll
just be hurting existing codebases on upgrading and more user
education
is
required to understand non-visual changes in syntax like this, lets
try
to
learn from our mistakes by not changing 'behaviour' anymore.

An alternative syntax that is similar and not ugly would be good
since
the
?: behaviour was broken from the start since you still need to run
isset()
before running ?: which was the problem we tried to solve in the
first
place but it just didn't happen.

I don't like the @ symbol it's too different from what's already
there
on
the ternary logic.

Proposal: $foo = $arr['value'] ?:: "";

Thoughts?

The would break the assumption that a reference to an
uninitialized
value
would generate a notice, unless explicitly handled in the logic.

While I also would like to have something similar to ?: to handle
default
values for array keys, etc., this would change a fundamental
assumption
that as been in place for many years now. I'm not sure if that's
a
BC
break
that would be acceptable this late. An alternative operator may
be
more
suitable.

What do you think about using:

$foo = $foo @: 'default';

and possibly

$foo @= 'default';

The change proposed has also been discussed several times since
the
implementation of ?:. See the ifsetor-RFC:

https://wiki.php.net/rfc/ifsetor

It also contains links to the discussion around the feature back
then.

--mats

This seems like a cracking time to suggest:

$x ||= $y;

The difference? Anything left of the ? SHOULD fail if it is not set,
because you are using it in a condition which is dangerous and odd for
other types of condition, but adding in this new syntax (similar to
Ruby) would essentially evaluate to this:

empty($x) ? $y : $x;

This gives keeps the behavior of ternary operators working in the same
way, but adds what we want: the ability to nicely set defaults for
variables and array keys that may not be set.

To me this reads as $x = $x || $y like all the <OP>= binary operators.
So it
would definitely feel weird to use that syntax for something else...

--

--
Etienne Kneuss
http://www.colder.ch

It is not $x = $x || $y but $x || $x = $y.

http://www.rubyinside.com/what-rubys-double-pipe-or-equals-really-does-5488.html
Ternary is being used by us to set defaults, but it is not the only
use of ternary, so making it totally quieten potential warnings and
errors is a weird use of a ternary. It's one of those "we do it this
way because its all we have" options and going further down the road
of abusing ternaries for this functionality does not make the
situation more simple.

Currently:
 $foo = isset($foo) && $foo ? $foo : 'default';
Proposed change by OP (with BC break):
$foo = $foo ?: 'default';
New ternary suggested by others, with "error suppressing":
$foo = $foo ??: 'default';
People will try using that with all sorts of other operators involved.
What happens when you do $foo = $foo == 'bar' ??: 'default'; It gets
complicated.
$foo ||= 'default';
Pretty obvious what is happening. If foo is falsey it will use
'default'. We can wrap $foo in isset or empty and make it more
durable, which certainly would take care of the OP's concerns without
breaking the way ternaries currently work - which is not actually
broken just not very handy at setting defaults for non-existent
variables.

11 years ago by Jezz Goodwin — view source

unread

On Tue, Nov 26, 2013 at 7:46 PM, Peter Cowburn petercowburn@gmail.comwrote:

Hi,

Before mentioning anything about new syntax, I thought I'd point out that
this code is already possible for setting defaults:

(isset($foo)) ?: $foo = 'default';

or

isset($foo) ?: $foo = 'default';

(I personally prefer wrapping the condition within brackets)

Saying that, I do think a syntax for setting defaults which doesn't
involve
typing the variable name twice would be nice.

My favourite one listed so far is:

$foo ?= 'default';

I like that too.

Elaborating on that idea, here’s one idea from a while back, making much
wider use of a “?” operator… https://gist.github.com/salathe/3256826

I worry sometimes that new syntax features are suggested for cleverness
sake and not for making code 'better'. My definition of better code is code
that is easy to read, concise, easy to maintain and ideally has good
performance.

Personally I think this feature can be used to make better code.

For example, I use a utility function to make writing default variable
values cleaner:

function fallback ( &$var, $default=null ) {
if (!isset($var)) {
$var = $default;
}
}

So, within other functions I use code like this:

fallback($name, 'no name');

The main thing that bugs me about using this code is that it has to invoke
a function to do it's work. If you've got lots of default values, it's a
lot of function calls. This new syntax would lower the number of function
calls, and be just as concise.

Footnote:
Although not quite the same subject, another way to increase performance
with this type of code would be a way to tell the parser to inline
functions. I'd love to be able to write 'inline function fallback ...' and
be able to give my code better grammar without the performance penalty.