# what happened to that new isset() like language construct - Thread: https://externals.io/message/10963 - Original archive: https://news-web.php.net/php.internals/10963 - Started by Jason Garber on 2004-07-08T00:39:40+00:00 - Messages: 42 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/10963.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #10963 — Jason Garber — 2004-07-08T00:39:40+00:00 URL: https://externals.io/message/10963#10963 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 --- ## #10964 — Marc Richards — 2004-07-08T01:06:43+00:00 URL: https://externals.io/message/10963#10964 · In reply to: #10963 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? --- ## #10965 — Jason Garber — 2004-07-08T01:20:34+00:00 URL: https://externals.io/message/10963#10965 · In reply to: #10963 Hi Marc, At 7/7/2004 09:06 PM -0400, Marc Richards wrote: >Jason Garber wrote: > > > […] > >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. > > […] > >5.1? Yep. >-- > > -Jason --- ## #10981 — Christian Schneider — 2004-07-08T15:13:36+00:00 URL: https://externals.io/message/10963#10981 · In reply to: #10963 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 --- ## #10983 — Marc Richards — 2004-07-08T15:18:31+00:00 URL: https://externals.io/message/10963#10983 · In reply to: #10981 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 --- ## #10985 — Rasmus Lerdorf — 2004-07-08T16:31:18+00:00 URL: https://externals.io/message/10963#10985 · In reply to: #10983 > Christian Schneider wrote: > > > […] > > 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 --- ## #10986 — Derrell.Lipman@UnwiredUniverse.com — 2004-07-08T16:40:37+00:00 URL: https://externals.io/message/10963#10986 · In reply to: #10981 Christian Schneider 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 --- ## #10989 — Marcus Boerger — 2004-07-08T18:53:34+00:00 URL: https://externals.io/message/10963#10989 · In reply to: #10981 Hello Christian, Thursday, July 8, 2004, 5:13:36 PM, you wrote: > Jason Garber 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. 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 --- ## #10990 — Christian Schneider — 2004-07-08T20:42:51+00:00 URL: https://externals.io/message/10963#10990 · In reply to: #10989 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 --- ## #10991 — Marc Richards — 2004-07-08T21:51:41+00:00 URL: https://externals.io/message/10963#10991 · In reply to: #10985 Rasmus Lerdorf wrote: > > > > […] > > > 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 --- ## #10993 — Rasmus Lerdorf — 2004-07-08T21:57:13+00:00 URL: https://externals.io/message/10963#10993 · In reply to: #10991 > 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 --- ## #10994 — Marc Richards — 2004-07-08T22:19:41+00:00 URL: https://externals.io/message/10963#10994 · In reply to: #10993 Rasmus Lerdorf wrote: > > > > […] > > > 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. > > […] > > > 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 --- ## #10996 — Rasmus Lerdorf — 2004-07-08T22:33:54+00:00 URL: https://externals.io/message/10963#10996 · In reply to: #10994 > Rasmus Lerdorf wrote: > > […] > > 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 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 --- ## #10997 — Olivier Hill — 2004-07-08T23:03:49+00:00 URL: https://externals.io/message/10963#10997 · In reply to: #10991 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+(?) --- ## #10998 — Marc Richards — 2004-07-08T23:10:19+00:00 URL: https://externals.io/message/10963#10998 · In reply to: #10997 Olivier Hill wrote: > Marc Richards wrote: > > > […] > > > Well.. yes and no... > > If you are afraid of making mistake, you can force yourself to never use > += -= *= operators, because you can simply write $a = $a + $b > > But if PHP introduces the ?: operator, you have to use it and there is > no other way around. What? Why? There is obviously a way around it, because that is what people are using now. $a = $b ? $b : $c; Marc --- ## #11001 — Olivier Hill — 2004-07-08T23:15:26+00:00 URL: https://externals.io/message/10963#11001 · In reply to: #10998 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+(?) --- ## #11004 — Marc Richards — 2004-07-08T23:33:02+00:00 URL: https://externals.io/message/10963#11004 · In reply to: #10996 Rasmus Lerdorf wrote: > > > > […] > > > 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(). > > […] > > > += 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 --- ## #11005 — Marc Richards — 2004-07-08T23:36:16+00:00 URL: https://externals.io/message/10963#11005 · In reply to: #11001 Olivier Hill wrote: > Marc Richards wrote: > > > […] > > > 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 --- ## #11006 — Adam Maccabee Trachtenberg — 2004-07-08T23:41:38+00:00 URL: https://externals.io/message/10963#11006 · In reply to: #11004 > 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! --- ## #11008 — Marc Richards — 2004-07-08T23:53:16+00:00 URL: https://externals.io/message/10963#11008 · In reply to: #11006 Adam Maccabee Trachtenberg wrote: > > > > […] > > > 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 --- ## #11010 — Johannes Schlueter — 2004-07-09T00:50:22+00:00 URL: https://externals.io/message/10963#11010 · In reply to: #11004 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 --- ## #11012 — Daniel Crookston — 2004-07-09T02:33:42+00:00 URL: https://externals.io/message/10963#11012 · In reply to: #11008 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. --- ## #11014 — Marcus Boerger — 2004-07-09T06:48:00+00:00 URL: https://externals.io/message/10963#11014 · In reply to: #11004 Hello Marc, Friday, July 9, 2004, 1:33:02 AM, you wrote: > Rasmus Lerdorf 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. > > […] > 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(). > > […] > Are you saying PHP will never introduce an operator that doesn't already > exist in a large number of other languages? > > […] > 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 --- ## #11015 — Marcus Boerger — 2004-07-09T06:49:04+00:00 URL: https://externals.io/message/10963#11015 · In reply to: #11012 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 --- ## #11023 — Derick Rethans — 2004-07-09T07:58:28+00:00 URL: https://externals.io/message/10963#11023 · In reply to: #11005 > 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 --- Next page: https://externals.io/message/10963.md?page=2