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:
On 4/15/2004 Jason Garber asked about a new language construct to simplify
testing if a variable isset() and assinging a default value for those that
aren't. The thread title was "Construct Request".I rember reading it while the discussion went on, I just went back and
browsed through it again. Everyone seemed to agree the it was generally a
good idea and there was some minimal amount of consensus on the ?: syntax,
but I can't tell if this was ever implemented.Was it? If not did I miss the reason why?
Marc
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?
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.
--
-Jason
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
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
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
Rasmus Lerdorf 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
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
Rasmus Lerdorf 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 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
Rasmus Lerdorf wrote:
Rasmus Lerdorf 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
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!
Adam Maccabee Trachtenberg wrote:
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.
Good point. As you can probably guess, I just made it up on a whim.
Like I said, I am on the fence about "marketing" it as related to the
ternary operator. But the fact still remains that if we did go with
this syntax, we could and probably should find a name for it.
Marc
Why not just call it the issetor, or the setor operator? Also, why does
www.php.net/ternary not link to what one would assume it might link to? We
could do the same with www.php.net/setor.
Dan
But the fact still remains that if we did go with
this syntax, we could and probably should find a name for it.
Hello Daniel,
Friday, July 9, 2004, 4:33:42 AM, you wrote:
Why not just call it the issetor, or the setor operator?
That's the point here. How shall we call the new operator.
--
Best regards,
Marcus mailto:helly@php.net
Hello Daniel,
Friday, July 9, 2004, 4:33:42 AM, you wrote:
Why not just call it the issetor, or the setor operator?
That's the point here. How shall we call the new operator.
I'm +1 on the "coalesce" name since I even think having the funciton
support multiple parameters and return the first set/not null value
would provide more utility to developers.
Cheers,
Rob.
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
Hello Robert,
coalesce would be:
"coalesce" "(" <var> ( "," <var> )* [ "," <expr> ] ")"
and would also require heay engine patching. I am speaking of a
really major change here, i already looked into what it would
need month's ago. Since the operator i proposed is different from
the coalesce functionality many sql developers know i see that as
a definitive no. But again if you give the engine a try :-)
mfG
marcus
Friday, July 9, 2004, 5:25:22 PM, you wrote:
Hello Daniel,
Friday, July 9, 2004, 4:33:42 AM, you wrote:
Why not just call it the issetor, or the setor operator?
That's the point here. How shall we call the new operator.
I'm +1 on the "coalesce" name since I even think having the funciton
support multiple parameters and return the first set/not null value
would provide more utility to developers.
Cheers,
Rob.
--
Best regards,
Marcus mailto:helly@php.net
Hello Robert,
coalesce would be:
"coalesce" "(" <var> ( "," <var> )* [ "," <expr> ] ")"
and would also require heay engine patching. I am speaking of a
really major change here, i already looked into what it would
need month's ago. Since the operator i proposed is different from
the coalesce functionality many sql developers know i see that as
a definitive no. But again if you give the engine a try :-)
Sorry, I thought I was following the thread quite thoroughly, but I
missed the part until earlier today where the functionality would
involve shortcutting expression evaluation if a non-null or set value
was found. Obviously (I think -- correct me if I'm wrong) without the
shortcutting feature, implementation would be simplistic.
Cheers,
Rob.
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
Hello Robert,
Saturday, July 10, 2004, 3:12:09 AM, you wrote:
Hello Robert,
coalesce would be:
"coalesce" "(" <var> ( "," <var> )* [ "," <expr> ] ")"
and would also require heay engine patching. I am speaking of a
really major change here, i already looked into what it would
need month's ago. Since the operator i proposed is different from
the coalesce functionality many sql developers know i see that as
a definitive no. But again if you give the engine a try :-)
Sorry, I thought I was following the thread quite thoroughly, but I
missed the part until earlier today where the functionality would
involve shortcutting expression evaluation if a non-null or set value
was found. Obviously (I think -- correct me if I'm wrong) without the
shortcutting feature, implementation would be simplistic.
The problem here is computing the jump addresses and targets needed.
Best regards,
Marcus mailto:helly@php.net
Hi,
I would suggest another name for ifsetor.
In relational databases, there is a similar function, called NVL in oracle,
and
IFNULL in MySQL and coalesce in postgresql for testing for null, and
returning
a default value if the variable is null.
I think ifsetor sounds a big ugly. I would suggest ifset($var,
$defaultvalue),
as there are historical analogies with mysql's IFNULL function, and i think
ifset looks different enough from isset, thanks to the tall 'F'.
$var = isset($aval) ? $aval : 0;
$var = ifset($aval, 0);
Thanks, John
"Daniel Crookston" daniel@hyperion-data.net wrote in message
news:007201c4655d$283125d0$6601a8c0@calhoun...
Why not just call it the issetor, or the setor operator? Also, why does
www.php.net/ternary not link to what one would assume it might link to?
We
could do the same with www.php.net/setor.Dan
But the fact still remains that if we did go with
this syntax, we could and probably should find a name for it.
Hello John,
we are not testing against NULL here. We check for existance.
That would be having a uniform sql way to test the existance of
a table or column in a table. Hence IFNULL(), NOT IFNULL(),
NVL() are different. I also explained several times why coalesce
doesn't apply.
Friday, July 9, 2004, 6:42:10 PM, you wrote:
Hi,
I would suggest another name for ifsetor.
In relational databases, there is a similar function, called NVL in oracle,
and IFNULL in MySQL and coalesce in postgresql for testing for null, and
returning a default value if the variable is null.
I think ifsetor sounds a big ugly. I would suggest ifset($var,
$defaultvalue), as there are historical analogies with mysql's
IFNULL function, and i think ifset looks different enough from
isset, thanks to the tall 'F'.
read top...IFNULL === is_null which has nothing to do with isset()
$var = isset($aval) ? $aval : 0;
$var = ifset($aval, 0);
That suggests it returns 0 if $val is set and not what you describe above.
To explain why i chose "ifsetor" try to read it as:
"if" <var> "set" return it "or" return <expr>
regards
marcus
Adam Maccabee Trachtenberg 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.
maybe call it the Collapsed Ternary (the first two arguments being
collapse into 1 because they are 'identical'*). document it under the
tenary docs, that way you can effectively introduce the std concept
first before showing the the PHP handy extra for all those blasted checks.
*sorry, my grasp of technical terminology is abysmal.
-adam
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
Hello Marc,
Friday, July 9, 2004, 1:33:02 AM, you wrote:
Rasmus Lerdorf wrote:
Rasmus Lerdorf 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
Marcus, or anyone else familiar enough with the engine,
Just to clarify, do you see an inherent technical problem with nesting
ifsetor() function calls?
$user = ifsetor($_SESSION['user'], ifsetor($_POST['user'], NULL));
or is the problem only with accepting a list of parameters:
$user = ifsetor($_SESSION['user'], $_POST['user'], NULL);
Marc
Hello Marc,
you can use my patch to test....
The second parameter can be any expression. Hence another
ifsetor() should be possible (if not we'd fix that).
marcus
Friday, July 9, 2004, 8:48:12 PM, you wrote:
Marcus, or anyone else familiar enough with the engine,
Just to clarify, do you see an inherent technical problem with nesting
ifsetor() function calls?
$user = ifsetor($_SESSION['user'], ifsetor($_POST['user'], NULL));
or is the problem only with accepting a list of parameters:
$user = ifsetor($_SESSION['user'], $_POST['user'], NULL);
Marc
--
Best regards,
Marcus mailto:helly@php.net
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
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
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".
And you could make a case for similar operators existing in perl (eq vs
==, which are of course slightly different).
George
Hello George,
Friday, July 9, 2004, 8:56:15 PM, you 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".
And you could make a case for similar operators existing in perl (eq vs
==, which are of course slightly different).
Looking at the confusion we started by simply having a different order in
evaluating the ternary operator i won't recomment starting to introduce new
operators like ?: that would definitively confuse everybody and tend to
erroneous code because it is too easy to misuse them by mistake....so lets
keep with that rule.
marcus
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".
This rule would favor the "a ? : b" notation - which has
been supported by GCC for at least five years.
- Sascha
Sascha Schumann wrote:
This rule would favor the "a ? : b" notation - which has been supported by GCC for at least five years.
My personal reasons against ?: :
- It's non-standard and not well known even though GCC supports it.
- It's hard to look up.
- It's easily confused with $a ? $b : $c;
- It's ugly (-:C
I'd even prefer the Perl 6 err operator over it which is '//' or 'err'
(low precedence) but then // is already the C++-style comment which I
wish we hadn't introduced to PHP to start with :-)
But unless convinced otherwise I think a pseudo-function like coalesce()
is the way to go.
- Chris
Hello Christian,
Saturday, July 10, 2004, 10:46:51 AM, you wrote:
Sascha Schumann wrote:
This rule would favor the "a ? : b" notation - which has been supported by GCC for at least five years.
My personal reasons against ?: :
- It's non-standard and not well known even though GCC supports it.
- It's hard to look up.
- It's easily confused with $a ? $b : $c;
- It's ugly (-:C
Yeah all good reasons against.
Maybe i could add that GCC's ?: is different from the intended behavior
because we are doing "isset($a) ? $a : $b" in contrast to "$a ? $a : $b"
Best regards,
Marcus mailto:helly@php.net
This rule would favor the "a ? : b" notation - which has been supported by GCC for at least five years.My personal reasons against ?: :
- It's non-standard and not well known even though GCC supports it.
- It's hard to look up.
- It's easily confused with $a ? $b : $c;
- It's ugly (-:C
Yeah all good reasons against.
Maybe i could add that GCC's ?: is different from the intended behavior
because we are doing "isset($a) ? $a : $b" in contrast to "$a ? $a : $b"
Looks like you guys misunderstand (my reply was to Rasmus
regarding the don't-make-up-new-operators guideline). My
original proposal (which dates back a couple of years) was
adding GCC semantics to PHP's tertiary operator. The
isset-thread is a separate issue.
- Sascha
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+(?)
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 + $bBut 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
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+(?)
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
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
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
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
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