Hey all. Been a while since I popped into this list. You may remember me from such emails as “Why god can’t we have namespaces”, or “so we’re still not fixing strpos, eh?”
I had a question-suggestion based around the cool new operator we’re getting in PHP7, the ?? operator, which as I understand it is the functional equivalent to perl’s // operator; in that they both test for whether or not a variable is defined, rather than it’s truthiness.
That’s all well and good, but one of the things that makes the || operator in javascript so handy is that definedness and truthiness go hand in hand, and an undefined value will simply evaluate to null/false, making things like (foo || false || true) possible, which is quite handy in a lot of situations. It seems like if we already have a construct in place that’ll bypass raising an E_NOTICE, it should possible to implement a secondary operator that tests for truthiness with similar semantics.
Something like, $config->auto_play = $config->auto_play ?! $defaults->auto_play ?! false;
Do you feel me? Guys?
-M
Hi,
shadda wrote:
I had a question-suggestion based around the cool new operator we’re getting in PHP7, the ?? operator, which as I understand it is the functional equivalent to perl’s // operator; in that they both test for whether or not a variable is defined, rather than it’s truthiness.
This is not strictly correct. Though something of a misnomer, the 'null
coalesce operator' checks if a variable doesn't exist, but also that it
is not null, i.e. it functions like isset().
Thanks.
--
Andrea Faulds
http://ajf.me/
Hey, thanks for responding.
However, I still think that misses the point, or at least the true utility of what I’m proposing.
In practice, you can ignore E_NOTICE and php will happily treat null and !isset() as the same thing in most cases, so that’s not a good indicator of truthiness.
Basically in ECMA, anything non-null, false, or undefined is true. PHP is very similar in that regard, but our reliance on E_NOTICE to (ahem) enforce isset() checks is why, I assume, we’re introducing the ?? operator to begin with.
I just think it’d be nice to have a small variation on this feature that was less concerned with a (defined|null) semantic and more in keeping with PHP’s overall handling of implicit type conversion in expressions.
Does that make more sense?
Hi,
shadda wrote:
I had a question-suggestion based around the cool new operator we’re getting in PHP7, the ?? operator, which as I understand it is the functional equivalent to perl’s // operator; in that they both test for whether or not a variable is defined, rather than it’s truthiness.
This is not strictly correct. Though something of a misnomer, the 'null coalesce operator' checks if a variable doesn't exist, but also that it is not null, i.e. it functions like isset().
Thanks.
--
Andrea Faulds
http://ajf.me/
Er, that should read, “anything non (null, false, undefined) is true”
Hey, thanks for responding.
However, I still think that misses the point, or at least the true utility of what I’m proposing.
In practice, you can ignore
E_NOTICEand php will happily treat null and !isset() as the same thing in most cases, so that’s not a good indicator of truthiness.Basically in ECMA, anything non-null, false, or undefined is true. PHP is very similar in that regard, but our reliance on
E_NOTICEto (ahem) enforce isset() checks is why, I assume, we’re introducing the ?? operator to begin with.I just think it’d be nice to have a small variation on this feature that was less concerned with a (defined|null) semantic and more in keeping with PHP’s overall handling of implicit type conversion in expressions.
Does that make more sense?
Hi,
shadda wrote:
I had a question-suggestion based around the cool new operator we’re getting in PHP7, the ?? operator, which as I understand it is the functional equivalent to perl’s // operator; in that they both test for whether or not a variable is defined, rather than it’s truthiness.
This is not strictly correct. Though something of a misnomer, the 'null coalesce operator' checks if a variable doesn't exist, but also that it is not null, i.e. it functions like isset().
Thanks.
--
Andrea Faulds
http://ajf.me/
Er, that should read, “anything non (null, false, undefined) is true”
Hey, thanks for responding.
However, I still think that misses the point, or at least the true utility of what I’m proposing.
In practice, you can ignore
E_NOTICEand php will happily treat null and !isset() as the same thing in most cases, so that’s not a good indicator of truthiness.Basically in ECMA, anything non-null, false, or undefined is true. PHP is very similar in that regard, but our reliance on
E_NOTICEto (ahem) enforce isset() checks is why, I assume, we’re introducing the ?? operator to begin with.I just think it’d be nice to have a small variation on this feature that was less concerned with a (defined|null) semantic and more in keeping with PHP’s overall handling of implicit type conversion in expressions.
Does that make more sense?
Hi,
shadda wrote:
I had a question-suggestion based around the cool new operator we’re getting in PHP7, the ?? operator, which as I understand it is the functional equivalent to perl’s // operator; in that they both test for whether or not a variable is defined, rather than it’s truthiness.
This is not strictly correct. Though something of a misnomer, the 'null coalesce operator' checks if a variable doesn't exist, but also that it is not null, i.e. it functions like isset().
Thanks.
--
Andrea Faulds
http://ajf.me/--
--
Ignoring E_NOTICE is generally considered bad practice by many, and
turning them off just to use ternaries instead of null coalesce (a
feature we already have) doesn't seem like a benefit.
The ?? is used the same as "a = b || c" in Ruby or JS. Doing that in
PHP wouldn't work well as || works a bit differently, so ?? is used
instead, just like C and Swift.
Basically... it's all good. And even if you hate it you're months too
late to raise a concern. :)
It’s not hate, I happen to like that ?? was added. I’m not raising a concern nor asking for a change in its behavior. Rather, I’m asking for another, similar operator that’s based on truth-evaluation (with PHP’s tender, loving conversion rules baked in), in addition to ?? which tests for null/undefined exclusively.
Er, that should read, “anything non (null, false, undefined) is true”
Hey, thanks for responding.
However, I still think that misses the point, or at least the true utility of what I’m proposing.
In practice, you can ignore
E_NOTICEand php will happily treat null and !isset() as the same thing in most cases, so that’s not a good indicator of truthiness.Basically in ECMA, anything non-null, false, or undefined is true. PHP is very similar in that regard, but our reliance on
E_NOTICEto (ahem) enforce isset() checks is why, I assume, we’re introducing the ?? operator to begin with.I just think it’d be nice to have a small variation on this feature that was less concerned with a (defined|null) semantic and more in keeping with PHP’s overall handling of implicit type conversion in expressions.
Does that make more sense?
Hi,
shadda wrote:
I had a question-suggestion based around the cool new operator we’re getting in PHP7, the ?? operator, which as I understand it is the functional equivalent to perl’s // operator; in that they both test for whether or not a variable is defined, rather than it’s truthiness.
This is not strictly correct. Though something of a misnomer, the 'null coalesce operator' checks if a variable doesn't exist, but also that it is not null, i.e. it functions like isset().
Thanks.
--
Andrea Faulds
http://ajf.me/--
--
Ignoring
E_NOTICEis generally considered bad practice by many, and
turning them off just to use ternaries instead of null coalesce (a
feature we already have) doesn't seem like a benefit.The ?? is used the same as "a = b || c" in Ruby or JS. Doing that in
PHP wouldn't work well as || works a bit differently, so ?? is used
instead, just like C and Swift.Basically... it's all good. And even if you hate it you're months too
late to raise a concern. :)
Well use null coalesce + elvis together then?
// Coalesce possible null values, and use truthy comparison in elvis to
"coalesce" to a default
$var = ($_GET['possible_value'] ?? $_COOKIE['secondary'] ?? false) ?:
DEFAULTS['var'];
It’s not hate, I happen to like that ?? was added. I’m not raising a
concern nor asking for a change in its behavior. Rather, I’m asking for
another, similar operator that’s based on truth-evaluation (with PHP’s
tender, loving conversion rules baked in), in addition to ?? which tests
for null/undefined exclusively.On Nov 23, 2015, at 12:08 PM, Phil Sturgeon pjsturgeon@gmail.com
wrote:Er, that should read, “anything non (null, false, undefined) is true”
Hey, thanks for responding.
However, I still think that misses the point, or at least the true
utility of what I’m proposing.In practice, you can ignore
E_NOTICEand php will happily treat null
and !isset() as the same thing in most cases, so that’s not a good
indicator of truthiness.Basically in ECMA, anything non-null, false, or undefined is true. PHP
is very similar in that regard, but our reliance onE_NOTICEto (ahem)
enforce isset() checks is why, I assume, we’re introducing the ?? operator
to begin with.I just think it’d be nice to have a small variation on this feature
that was less concerned with a (defined|null) semantic and more in keeping
with PHP’s overall handling of implicit type conversion in expressions.Does that make more sense?
Hi,
shadda wrote:
I had a question-suggestion based around the cool new operator we’re
getting in PHP7, the ?? operator, which as I understand it is the
functional equivalent to perl’s // operator; in that they both test for
whether or not a variable is defined, rather than it’s truthiness.This is not strictly correct. Though something of a misnomer, the
'null coalesce operator' checks if a variable doesn't exist, but also that
it is not null, i.e. it functions like isset().Thanks.
--
Andrea Faulds
http://ajf.me/--
--
Ignoring
E_NOTICEis generally considered bad practice by many, and
turning them off just to use ternaries instead of null coalesce (a
feature we already have) doesn't seem like a benefit.The ?? is used the same as "a = b || c" in Ruby or JS. Doing that in
PHP wouldn't work well as || works a bit differently, so ?? is used
instead, just like C and Swift.Basically... it's all good. And even if you hate it you're months too
late to raise a concern. :)
That’s not a bad idea, but it’s still limited in certain cases, where your list of possibles is, lets say, complex.
At this point, I think you guys get what I’m after, and I’m wondering if anyone else finds the idea as useful I as do.
In fact, if it didn’t break the One Law of PHP (thou shalt not break BC), I might even suggest just giving ?: the same super power as ??, in not throwing a notice.
Well use null coalesce + elvis together then?
// Coalesce possible null values, and use truthy comparison in elvis to "coalesce" to a default
$var = ($_GET['possible_value'] ?? $_COOKIE['secondary'] ?? false) ?: DEFAULTS['var'];It’s not hate, I happen to like that ?? was added. I’m not raising a concern nor asking for a change in its behavior. Rather, I’m asking for another, similar operator that’s based on truth-evaluation (with PHP’s tender, loving conversion rules baked in), in addition to ?? which tests for null/undefined exclusively.
Er, that should read, “anything non (null, false, undefined) is true”
Hey, thanks for responding.
However, I still think that misses the point, or at least the true utility of what I’m proposing.
In practice, you can ignore
E_NOTICEand php will happily treat null and !isset() as the same thing in most cases, so that’s not a good indicator of truthiness.Basically in ECMA, anything non-null, false, or undefined is true. PHP is very similar in that regard, but our reliance on
E_NOTICEto (ahem) enforce isset() checks is why, I assume, we’re introducing the ?? operator to begin with.I just think it’d be nice to have a small variation on this feature that was less concerned with a (defined|null) semantic and more in keeping with PHP’s overall handling of implicit type conversion in expressions.
Does that make more sense?
Hi,
shadda wrote:
I had a question-suggestion based around the cool new operator we’re getting in PHP7, the ?? operator, which as I understand it is the functional equivalent to perl’s // operator; in that they both test for whether or not a variable is defined, rather than it’s truthiness.
This is not strictly correct. Though something of a misnomer, the 'null coalesce operator' checks if a variable doesn't exist, but also that it is not null, i.e. it functions like isset().
Thanks.
--
Andrea Faulds
http://ajf.me/ http://ajf.me/--
--
Ignoring
E_NOTICEis generally considered bad practice by many, and
turning them off just to use ternaries instead of null coalesce (a
feature we already have) doesn't seem like a benefit.The ?? is used the same as "a = b || c" in Ruby or JS. Doing that in
PHP wouldn't work well as || works a bit differently, so ?? is used
instead, just like C and Swift.Basically... it's all good. And even if you hate it you're months too
late to raise a concern. :)--
Hi,
shadda wrote:
That’s not a bad idea, but it’s still limited in certain cases, where your list of possibles is, lets say, complex.
At this point, I think you guys get what I’m after, and I’m wondering if anyone else finds the idea as useful I as do.In fact, if it didn’t break the One Law of PHP (thou shalt not break BC), I might even suggest just giving ?: the same super power as ??, in not throwing a notice.
This is what my RFC for the null coalesce operator was originally going
to do: make ?: use empty(). However, it was deemed a better idea to add
a new operator, ??, which uses isset(), since a falsy value != a missing
value.
Thanks.
--
Andrea Faulds
http://ajf.me/
In practice, you can ignore
E_NOTICEand php will happily treat null and !isset() as the same thing in most cases, so that’s not a good indicator of truthiness.
If you really believe that then this is all you need already:
$database = $config['database'] ?: 'db';
Correct?
Oh, please, by no means take that as an endorsement for dropping error reporting levels. It was just an observation of how PHP actually derives a conditional in those situations. It’s not as if there’s a fatality in script execution when you make that kind of comparison, it’s just a really shitty way to code. In fact, it’s also why i typically avoid empty(). Nevertheless, PHP lacks a concise solution for dealing with multiple possibly-false-evaluating values.
Hacks like my coalesce() function that rely on the side effect of reference-passing can only go so far, as there’s also no way to pass &N references (at least that I’m aware of, correct me if I’m wrong)
I mean really I just want to be able to easily and lazily handle situations where I’ve got several vars as possible values in an assignment or expression, without chaining lots of function calls. Perhaps if empty() took N params like isset() does, but that’s only a nudge in the, er, “right” direction.
In practice, you can ignore
E_NOTICEand php will happily treat null and !isset() as the same thing in most cases, so that’s not a good indicator of truthiness.If you really believe that then this is all you need already:
$database = $config['database'] ?: 'db';
Correct?