# what happened to that new isset() like language construct - Thread: https://externals.io/message/10962 - Original archive: https://news-web.php.net/php.internals/10962 - Started by Marc Richards on 2004-07-08T00:26:31+00:00 - Messages: 19 - 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 --- ## #10962 — Marc Richards — 2004-07-08T00:26:31+00:00 URL: https://externals.io/message/10962#10962 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 --- ## #10966 — Marcus Boerger — 2004-07-08T01:27:39+00:00 URL: https://externals.io/message/10962#10966 · In reply to: #10962 Hello Marc, it somply was far too lat3e in relase process. That's wy we ae all agreed to delay that until 5.1. Also we were very unsure about the name of such an operator....if you can collect all the ideas or can come up with ther perfect one!?! a patch is here: http://marcus-boerger.de/php/ext/ze2/ze2-ifsetor-20040416-4.diff.txt (maybe a little bit outdated) regards marcus Thursday, July 8, 2004, 2:26:31 AM, you 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 -- Best regards, Marcus mailto:helly@php.net --- ## #10979 — Marc Richards — 2004-07-08T14:07:54+00:00 URL: https://externals.io/message/10962#10979 · In reply to: #10966 Marcus Boerger wrote: > Hello Marc, > > it somply was far too lat3e in relase process. That's wy we ae all agreed > to delay that until 5.1. Also we were very unsure about the name of such > an operator....if you can collect all the ideas or can come up with ther > perfect one!?! > Well I'm partial to ?: and there seemed to be some support for it, but there also seemed to be a non-trivial (though not necessarily difficult) amount of work to get it to work right. ifsetor() is obviously less concise, but also the name at first glance is a little non-obvious/confusing. I suppose isset() suffers from the same problem, and people will eventuall get used to it. If the technical problems can be overcome, I'm all for ?: otherwise ifsetor() seemed like the best suggestion so far. I am far less qualified to come up with an alternative than the more experienced PHP'ers out there. Marc --- ## #10984 — Jay Smith — 2004-07-08T15:31:08+00:00 URL: https://externals.io/message/10962#10984 · In reply to: #10979 Marc Richards wrote: > > Well I'm partial to ?: and there seemed to be some support for it, but > there also seemed to be a non-trivial (though not necessarily difficult) > amount of work to get it to work right. > > ifsetor() is obviously less concise, but also the name at first glance > is a little non-obvious/confusing. I suppose isset() suffers from the > same problem, and people will eventuall get used to it. > > If the technical problems can be overcome, I'm all for ?: otherwise > ifsetor() seemed like the best suggestion so far. I am far less > qualified to come up with an alternative than the more experienced > PHP'ers out there. > > > Marc As far as the name is concerned, I'm kind of partial to coalesce(), as the purpose of the function is really similar to the SQL function of the same name. This is from the Postgres manual, although I think the function itself is from SQL99: "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)') ..." In effect, that's more or less what this function is supposed to as I understand it -- in PHP's case, it returns the first argument from its argument list that is set and has a value, if none is found it returns NULL. Personally, I like coalesce() if only because of my familiarity with the SQL function. I know that many PHP users are familiar with SQL, although how many are familiar with coalesce() is another matter. J --- ## #10987 — Marcus Boerger — 2004-07-08T18:48:11+00:00 URL: https://externals.io/message/10962#10987 · In reply to: #10984 Hello Jay, Thursday, July 8, 2004, 5:31:08 PM, you wrote: > Marc Richards wrote: > > […] > As far as the name is concerned, I'm kind of partial to coalesce(), as the > purpose of the function is really similar to the SQL function of the same > name. This is from the Postgres manual, although I think the function > itself is from SQL99: ifsetor is different. It only takes one variable and an optional default value (any expression). "ifsetor" "(" [ "," ] ")" Changing it to accept a list of *variables* could probably be possible but would require heavy restructuring of the compiler. The same is true for chaning it to accept a variable plus a list of expressions is even more complicated. Best regards, Marcus mailto:helly@php.net --- ## #10988 — Marcus Boerger — 2004-07-08T18:50:01+00:00 URL: https://externals.io/message/10962#10988 · In reply to: #10979 Hello Marc, Thursday, July 8, 2004, 4:07:54 PM, you wrote: > Marcus Boerger wrote: > > […] > Well I'm partial to ?: and there seemed to be some support for it, but > there also seemed to be a non-trivial (though not necessarily difficult) > amount of work to get it to work right. ?: would require a default value. ifsetor() allows to assume `NULL` hence the latter is more powerfull. Hence id like to see a new keyword. Best regards, Marcus mailto:helly@php.net --- ## #10992 — Marc Richards — 2004-07-08T21:54:59+00:00 URL: https://externals.io/message/10962#10992 · In reply to: #10988 Marcus Boerger wrote: > > ?: would require a default value. ifsetor() allows to assume `NULL` hence > the latter is more powerfull. Hence id like to see a new keyword. > Well am not sure what you mean by more powerful, but the character count is about the same: $a = ifsetor($b); $a = $b ?: NULL; And the second one has the advantage of being more verbose. Marc --- ## #10995 — Marcus Boerger — 2004-07-08T22:26:53+00:00 URL: https://externals.io/message/10962#10995 · In reply to: #10992 Hello Marc, Thursday, July 8, 2004, 11:54:59 PM, you wrote: > Marcus Boerger wrote: > > […] > Well am not sure what you mean by more powerful, but the character count > is about the same: > $a = ifsetor($b); it would allow two versions by having the default optional: 1) $a = ifsetor($b) 2) $a = ifsetor($b, NULL) > $a = $b ?: NULL; How would the operator do the second? Will it look like the following? $a = $b ?:; I defitively don't want that. > And the second one has the advantage of being more verbose. That's why ifsetor has two versions. regards marcus --- ## #11000 — Marc Richards — 2004-07-08T23:13:28+00:00 URL: https://externals.io/message/10962#11000 · In reply to: #10995 Marcus Boerger wrote: > > it would allow two versions by having the default optional: > > 1) $a = ifsetor($b) > 2) $a = ifsetor($b, NULL) > > > > […] > > > How would the operator do the second? Will it look like the > following? > > $a = $b ?:; > > I defitively don't want that. > Me either. What I am saying is that there is no need for two versions. $a = $b ?: NULL; is as concise as the first version, and as explicit (in terms of the NULL) as the second. Marc --- ## #11083 — Marc Richards — 2004-07-11T02:49:57+00:00 URL: https://externals.io/message/10962#11083 · In reply to: #10962 Ok, so let me try to do a little summary. If and When ----------- 1) There seems to be a general consensus that this feature should be implemented in SOME way. 2) It was too late for 5.0.0 so it will be targeted for 5.1 What ---- The requirements seem be: a) return the first variable/expression that isset() b) no error shouldbe thrown for unset variables c) short circuit evaluation How --- 1) ?: has been rejected for the following reasons. - Possible confusion with the ternary operator - Asymmetry with the ternary operator - since it tests isset() - It is non-obvious in its functionality in and of itself - It would be difficult to find info on it in the Docs - There is no WIDESPREAD use in other languages (though it is used in GCC) and PHP has been very strict about not introducing new operators that are not already widely used (only 2 in 10 years) 2) Jason Garber suggested the following syntax: $a = $b setor $c; While I like the fact that it is an operator instead of function, and therefore eases the process of chaining multiple operations together, I see a problem. Most PHP operators use non-alphanumeric characters, therefore making it easier to quickly see the difference between variable names and operators. I believe the primary exceptions are "or", "and", and "xor". These were most likely added because of a similarity with perl and can kinda get away with it since they are so short. "setor" just doesn't look like an operator to me. 3) So this leaves a function call which begs two questions: What do we call it, and what is the function syntax. (a) What do we call it Various suggestions have been rejected because of similarity to existing keywords. These include: ifset(), ifelse(), ifexists() and probably a few more. We can't extend isset() perform this functionality because isset() already takes multiple parameters. nvl(), ifnull() and coalesce() have been proposed because of similar existing functions in Oracle, MySQL and Postgres. However Marcus has pointed out that these function test for null while we are testing for existence. I also think that since these functions are 1) not WIDELY used and 2) not terribly intuitively named (with the possible exception of coalesce) we should probably not use them unless we are unable to come up with something else. This currently leaves us with a hand full of names, including: ifsetor(), firstset(), getval()/getvalue()/get_value() (Is there a rule about underscores in new function names?). (b) What is the function syntax? Marcus has already looked into the issue and already created a patch, the existing patch only takes one variable and an optional default value (any expression). "ifsetor" "(" [ "," ] ")" According to Marcus: "Changing it to accept a list of *variables* could probably be possible but would require heavy restructuring of the compiler. The same is true for chaining it to accept a variable plus a list of expressions is even more complicated." Christian seem to be intent on trying to make it work, preferably with the following format: "coalesce" "(" ( "," )* ")" Andi thinks we should "make a decision what the best way to go is and then we can discuss implementation if/what is possible". They will both probably not have time to look at this until after 5.0 is out. My current preference is "getval" "(" ( "," )* ")" Marc 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 --- ## #11084 — Ilya Sher — 2004-07-11T08:22:26+00:00 URL: https://externals.io/message/10962#11084 · In reply to: #11083 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marc Richards wrote: | Ok, so let me try to do a little summary. | | | If and When | ----------- | 1) There seems to be a general consensus that this feature should be | implemented in SOME way. | 2) It was too late for 5.0.0 so it will be targeted for 5.1 | | | What | ---- | The requirements seem be: | a) return the first variable/expression that isset() | b) no error shouldbe thrown for unset variables | c) short circuit evaluation | | | | | How | --- | 1) ?: has been rejected for the following reasons. | - Possible confusion with the ternary operator | - Asymmetry with the ternary operator - since it tests isset() | - It is non-obvious in its functionality in and of itself | - It would be difficult to find info on it in the Docs | - There is no WIDESPREAD use in other languages (though it is used | in GCC) and PHP has been very strict about not introducing new operators | that are not already widely used (only 2 in 10 years) | | | 2) Jason Garber suggested the following syntax: $a = $b setor $c; $a = $b setor $c setor $d setor $e ... ? too verbose IMHO | | While I like the fact that it is an operator instead of function, and | therefore eases the process of chaining multiple operations together, I | see a problem. Most PHP operators use non-alphanumeric characters, | therefore making it easier to quickly see the difference between | variable names and operators. I believe the primary exceptions are | "or", "and", and "xor". These were most likely added because of a | similarity with perl and can kinda get away with it since they are so | short. "setor" just doesn't look like an operator to me. | | | 3) So this leaves a function call which begs two questions: What do we | call it, and what is the function syntax. | | (a) What do we call it | | Various suggestions have been rejected because of similarity to existing | keywords. These include: ifset(), ifelse(), ifexists() and probably a | few more. | | We can't extend isset() perform this functionality because isset() | already takes multiple parameters. | | nvl(), ifnull() and coalesce() have been proposed because of similar | existing functions in Oracle, MySQL and Postgres. However Marcus has | pointed out that these function test for null while we are testing for | existence. I also think that since these functions are 1) not WIDELY | used and 2) not terribly intuitively named (with the possible exception | of coalesce) we should probably not use them unless we are unable to | come up with something else. | | This currently leaves us with a hand full of names, including: | ifsetor(), firstset(), getval()/getvalue()/get_value() (Is there a rule | about underscores in new function names?). firstset() is most logical name (at least for me) | | | (b) What is the function syntax? | | Marcus has already looked into the issue and already created a patch, | the existing patch only takes one variable and an optional default | value (any expression). | | "ifsetor" "(" [ "," ] ")" | | According to Marcus: | | "Changing it to accept a list of *variables* could probably be possible | but would require heavy restructuring of the compiler. The same is true | for chaining it to accept a variable plus a list of expressions is even | more complicated." Seems like excepting multiple variables is worth the effort: firstset($_GET['x'],$_POST['x'],'') | | Christian seem to be intent on trying to make it work, preferably with | the following format: | | "coalesce" "(" ( "," )* ")" | | Andi thinks we should "make a decision what the best way to go is and | then we can discuss implementation if/what is possible". They will both | probably not have time to look at this until after 5.0 is out. | | | My current preference is | | "getval" "(" ( "," )* ")" "firstset" "(" ( "," )* ")" | | | | Marc | | | | | | 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 | | - -- PGP k: 3A4A 810C 1C81 79F3 A8C6 2545 90FD 6114 F730 0680 Rules: *NIX,UTF-8,Lisp,S-exps,FP,Encryption,OSS,VIM,Gnome Sucks: M$,XML,Bad Code,Morons on the Web,toy text editors Social Engineering - Because theres no patch for human stupidity. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA8PjBkP1hFPcwBoARAjfBAJ9FDYZQ6NJEGNLPLtIa4xWWWJzn9gCfa0eg l63mGYP5oa8RsXrTXETBu7s= =ktHL -----END PGP SIGNATURE --- ## #11088 — Marcus Boerger — 2004-07-11T14:15:52+00:00 URL: https://externals.io/message/10962#11088 · In reply to: #11083 Hello Marc, Sunday, July 11, 2004, 4:49:57 AM, you wrote: > Ok, so let me try to do a little summary. > If and When > ----------- > 1) There seems to be a general consensus that this feature should be > implemented in SOME way. > 2) It was too late for 5.0.0 so it will be targeted for 5.1 > What > ---- > The requirements seem be: > a) return the first variable/expression that isset() > b) no error shouldbe thrown for unset variables > c) short circuit evaluation > How > --- > 1) ?: has been rejected for the following reasons. > - Possible confusion with the ternary operator > - Asymmetry with the ternary operator - since it tests isset() > - It is non-obvious in its functionality in and of itself > - It would be difficult to find info on it in the Docs > - There is no WIDESPREAD use in other languages (though it is used in > GCC) and PHP has been very strict about not introducing new operators > that are not already widely used (only 2 in 10 years) > 2) Jason Garber suggested the following syntax: $a = $b setor $c; > While I like the fact that it is an operator instead of function, and > therefore eases the process of chaining multiple operations together, I > see a problem. Most PHP operators use non-alphanumeric characters, > therefore making it easier to quickly see the difference between > variable names and operators. I believe the primary exceptions are > "or", "and", and "xor". These were most likely added because of a > similarity with perl and can kinda get away with it since they are so > short. "setor" just doesn't look like an operator to me. > 3) So this leaves a function call which begs two questions: What do we > call it, and what is the function syntax. > (a) What do we call it > Various suggestions have been rejected because of similarity to existing > keywords. These include: ifset(), ifelse(), ifexists() and probably a > few more. > We can't extend isset() perform this functionality because isset() > already takes multiple parameters. > nvl(), ifnull() and coalesce() have been proposed because of similar > existing functions in Oracle, MySQL and Postgres. However Marcus has > pointed out that these function test for null while we are testing for > existence. I also think that since these functions are 1) not WIDELY > used and 2) not terribly intuitively named (with the possible exception > of coalesce) we should probably not use them unless we are unable to > come up with something else. > This currently leaves us with a hand full of names, including: > ifsetor(), firstset(), getval()/getvalue()/get_value() (Is there a rule > about underscores in new function names?). > (b) What is the function syntax? > Marcus has already looked into the issue and already created a patch, > the existing patch only takes one variable and an optional default > value (any expression). > "ifsetor" "(" [ "," ] ")" > According to Marcus: > "Changing it to accept a list of *variables* could probably be possible > but would require heavy restructuring of the compiler. The same is true > for chaining it to accept a variable plus a list of expressions is even > more complicated." > Christian seem to be intent on trying to make it work, preferably with > the following format: > "coalesce" "(" ( "," )* ")" > Andi thinks we should "make a decision what the best way to go is and > then we can discuss implementation if/what is possible". They will both > probably not have time to look at this until after 5.0 is out. > My current preference is > "getval" "(" ( "," )* ")" Marc, excellent work. While reading this again i only missed the obvious ability to nest ifsetor() calls (your own idea btw) to emulate coalesce. Anyway it may be the best idea to simply apply the patch for ifsetor and find a way to implement coalesce with exactly that name. I also think this is the way to go if enough people want coalesce because in the majority of time the situation that led to ifsetor doesn't require nor even has a need for coalesce. To me it seems the call for coalesce only occured because some people knew it from SQL and thought it could be more powerfull. BUT remember that situation. It is the need to write `E_NOTICE` free code and hence dealing with probably unset array indices or other uninitialized data most probably from some form input. There you currently need to do: $a = isset($_GET['index']) ? $_GET['index'] : $default; and this we want to change to: $a = ifsetor($_GET['index'], $default); and there is no need for coalesce. Coalesce comes into play when it gets more complicated like when you implement fall backs. And also the fallbacks are uninitialized. And again a but. But typically the fallbacks come from ini or whatever files or databases. For all these origins of data the values are define. If no we come to Marc's idea of nesting: $a = ifsetof($a, ifsetor($fallback, $default)); If it turns out that a majority of people require coalesce hopefully there is already a patch to apply :-) regards marcus --- ## #11089 — Rasmus Lerdorf — 2004-07-11T16:43:51+00:00 URL: https://externals.io/message/10962#11089 · In reply to: #11088 > $a = ifsetor($_GET['index'], $default); ifsetor() sounds a bit cumbersome to me. Some other suggestions: $a = is($_GET['index'], $default); $a = isor($_GET['index'], $default); $a = valid($_GET['index'], $default); $a = value($_GET['index'], $default); -Rasmus --- ## #11090 — Marc Richards — 2004-07-11T17:02:01+00:00 URL: https://externals.io/message/10962#11090 · In reply to: #11084 Ilya Sher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > firstset() is most logical name (at least for me) > | The problem with firstset() is that it doesn't make as much sense if we are only testing one variable...but that is still to be determined. Marc --- ## #11093 — Sterling Hughes — 2004-07-11T18:13:07+00:00 URL: https://externals.io/message/10962#11093 · In reply to: #11089 > > > > […] > > ifsetor() sounds a bit cumbersome to me. > > Some other suggestions: > > $a = is($_GET['index'], $default); > > $a = isor($_GET['index'], $default); > > $a = valid($_GET['index'], $default); I don't like valid, because that implies checks that aren't there (some sort of sanitizing). > > $a = value($_GET['index'], $default); > all of the other ones sound good - i like `value()` the best. -sterling --- ## #11094 — Curt Zirzow — 2004-07-11T18:44:06+00:00 URL: https://externals.io/message/10962#11094 · In reply to: #11089 * Thus wrote Rasmus Lerdorf: > > > > […] > > ifsetor() sounds a bit cumbersome to me. > > ... > > $a = value($_GET['index'], $default); I like `value()` although it might be a bit too generic, maybe add a word to it to help understand what the call does: $a = valueof($_GET['index'], $default); $a = valueor($_GET['index'], $default); Curt -- First, let me assure you that this is not one of those shady pyramid schemes you've been hearing about. No, sir. Our model is the trapezoid! --- ## #11100 — Johannes Schlueter — 2004-07-11T21:04:09+00:00 URL: https://externals.io/message/10962#11100 · In reply to: #11089 Rasmus Lerdorf wrote: > $a = value($_GET['index'], $default); imho value is a bit too generic, what about firstvalue() or first_set_value() or first_not_null()? johannes --- ## #11103 — Jason Garber — 2004-07-12T02:48:03+00:00 URL: https://externals.io/message/10962#11103 · In reply to: #11089 Hello, RL> $a = value($_GET['index'], $default); `value()` sounds like more like a "language construct" to me. I'm not sure if it accurately conveys the meaning though (not that it has stopped other functions from being added in the past :) -- Best regards, Jason mailto:jason@ionzoft.com --- ## #11121 — Bert Slagter — 2004-07-12T13:18:36+00:00 URL: https://externals.io/message/10962#11121 · In reply to: #11083 Marc Richards wrote: > 3) So this leaves a function call which begs two questions: What do we > call it, and what is the function syntax. > > (a) What do we call it We have a function that pretty much serves the same purpose: makeset($var, 'default'). The name was born because this function was made to replace a list of statements that make sure a variable is set: if (!isset($_REQUEST['foo'])) $_REQUEST['foo'] = 0; This is a function that takes its first argument by reference btw... But my point was the name, maybe some of you might like it :). Bert