Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » what happened to that new isset() like language construct »

what happened to that new isset() like language construct

php.internals

Marc Richards

22 years ago
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

Marcus Börger

22 years ago
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

Marc Richards

22 years ago
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

J Smith

22 years ago
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

Marcus Börger

22 years ago
Hello Jay, Thursday, July 8, 2004, 5:31:08 PM, you wrote:
> 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:
ifsetor is different. It only takes one variable and an optional default value (any expression). "ifsetor" "(" <variable> [ "," <expression> ] ")" 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

Marcus Börger

22 years ago
Hello Marc, Thursday, July 8, 2004, 4:07:54 PM, you wrote:
> 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.
?: 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

Marc Richards

22 years ago
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

Marcus Börger

22 years ago
Hello Marc, Thursday, July 8, 2004, 11:54:59 PM, you wrote:
> 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);
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

Marc Richards

22 years ago
Marcus Boerger wrote:
> > 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. >
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

Andi Gutmans

22 years ago
Personally I am not that fond of ifsetor(), but I am definitely not fond of ?: because of Marcus' reasons. At 12:26 AM 7/9/2004 +0200, Marcus Boerger wrote:

Guy N. Hurst

22 years ago
Andi Gutmans wrote:
> Personally I am not that fond of ifsetor(), but I am definitely not fond > of ?: because of Marcus' reasons. >
Here is a list of other possible names to ponder, with examples: // family: gettype, getenv, getopt, gets, getc getval() // $v = getval($_GET['v'],0); // $x = getval($_GET['x']); getv() // $v = getv($_GET['v'],0); // $x = getv($_GET['x']); getdefault() // $v = getdefault($_GET['v'],0); // $x = getdefault($_GET['x']); getd() // $v = getd($_GET['v'],0); // $x = getd($_GET['x']); // family: var_dump, var_export var_default() // $v = var_default($_GET['v'],0); // $x = var_default($_GET['x']); // family: floatval, intval, strval defaultval() // $v = defaultval($_GET['v'],0); // $x = defaultval($_GET['x']); shadowval() // $v = shadowval($_GET['v'],0); // $x = shadowval($_GET['x']); Guy N. Hurst

Marcus Börger

22 years ago
Hello & thanks Guy, a very constructive mail! Of yours i like getval() and var_default() and getdefault() a little bit. so atm i am in favor of either getval() or ifsetor(). marcus Saturday, July 10, 2004, 3:20:15 AM, you wrote:

Marc Richards

22 years ago
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" "(" <variable> [ "," <expression> ] ")" 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" "(" <expr> ( "," <expr> )* ")" 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" "(" <expr> ( "," <expr> )* ")" Marc Marc Richards wrote:

Ilya Sher

22 years ago
-----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" "(" <variable> [ "," <expression> ] ")" | | 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" "(" <expr> ( "," <expr> )* ")" | | 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" "(" <expr> ( "," <expr> )* ")" "firstset" "(" <expr> ( "," <expr> )* ")" | | | | 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-----

Marc Richards

22 years ago
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

Cris H

22 years ago
--- Marc Richards <contact_marcos@yahoo.es> wrote:
> 3) So this leaves a function call which begs two questions: > What do we call it,
[snip]
> These include: ifset(), ifelse(), ifexists() and
[snip]
> nvl(), ifnull() and coalesce() have been proposed because of > 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?).
I addition to these, and Guy N. Hurst's excellent suggestions, I thought I'd throw a few into the mix, just for the sake of ideas. fix() safe_init() discern() concretize() One wag here also suggested: php_variable_quantum_waveform_collapse() but the least said about that, the better ... Out of the above, I think fix() and safe_init() are the better ones, although they possibly run the risk of causing conflicts with existing code, and being initially misleading with regards to their purpose. If semantic clarity is the primary criterion, I don't think we'll do much better than ifsetor(). Semantically, though, fix() works in both senses and, importantly, is nice and short. regards, Cris ___________________________________________________________ALL-NEW Yahoo! Messenger - sooooo many all-new ways to express yourself http://uk.messenger.yahoo.com

Sean Coates

22 years ago
Not meaning to add more confusion, but Coldfusion (yes yes, please keep laughter to a minimum) has had a similar function since the beginning (IIRC). it's <cfparam ... > http://livedocs.macromedia.com/coldfusion/6.1/htmldocs/tags-b13.htm Perhaps a php function "param(...)" ? Even though it's not always a request parameter we'll (developers) be checking, this will be true in most cases. S [the following heavily edited:]

Marc Richards

22 years ago
Sean Coates wrote:
> Not meaning to add more confusion, but Coldfusion (yes yes, please keep > laughter to a minimum) has had a similar function since the beginning > (IIRC). > > it's <cfparam ... > > http://livedocs.macromedia.com/coldfusion/6.1/htmldocs/tags-b13.htm > > Perhaps a php function "param(...)" ? Even though it's not always a > request parameter we'll (developers) be checking, this will be true in > most cases.
I don't think a function named param() really fits, but I do like the idea of adding a type check (or in the case of PHP a type cast) to the function. $level = (int) (isset($_SESSION['level']) ? $_SESSION['level'] : (isset($_REQUEST['level']) ? $_REQUEST['level'] : 1)) becomes $level = value($_SESSION['level'], $_REQUEST['level'], 1, INT); Of course, I have no idea how feasible this is. Marc

Marc Richards

22 years ago
Marc Richards wrote:
> I don't think a function named param() really fits, but I do like the > idea of adding a type check (or in the case of PHP a type cast) to the > function. > > > $level = (int) (isset($_SESSION['level']) ? $_SESSION['level'] : > (isset($_REQUEST['level']) ? $_REQUEST['level'] : 1)) > > becomes > > $level = value($_SESSION['level'], $_REQUEST['level'], 1, INT); >
P.S. Aside from simply moving the type cast into the function, this would also avoid doing the cast on the default variable, which could be particularly useful if you want $level to be NULL...in which case it might be better to switch the order of the last two params since INT is "bound to" the variables, not the default $level = value($_SESSION['level'], $_REQUEST['level'], INT, 1); or $level = value($_SESSION['level'], $_REQUEST['level'], INT, NULL); or $level = value($_SESSION['level'], $_REQUEST['level'], INT); Marc

Rasmus Lerdorf

22 years ago
On Sun, 11 Jul 2004, Marc Richards wrote:
> Marc Richards wrote: > > > I don't think a function named param() really fits, but I do like the > > idea of adding a type check (or in the case of PHP a type cast) to the > > function. > > > > > > $level = (int) (isset($_SESSION['level']) ? $_SESSION['level'] : > > (isset($_REQUEST['level']) ? $_REQUEST['level'] : 1)) > > > > becomes > > > > $level = value($_SESSION['level'], $_REQUEST['level'], 1, INT); > > > > P.S. Aside from simply moving the type cast into the function, this > would also avoid doing the cast on the default variable, which could be > particularly useful if you want $level to be NULL...in which case it > might be better to switch the order of the last two params since INT is > "bound to" the variables, not the default > > $level = value($_SESSION['level'], $_REQUEST['level'], INT, 1); > > or > > $level = value($_SESSION['level'], $_REQUEST['level'], INT, NULL); > > or > > $level = value($_SESSION['level'], $_REQUEST['level'], INT);
This is starting to sound like the intval/floatval/strval functions that have been around for years and rarely used. We could simply soup these up a bit and thereby not add another function which could cause problems. Looks like it can be done without breaking backward compatibility too Of course, we would still need a version that didn't force the type, and in the case of the intval() function there is already a second optional arg whch specifies the base, so it isn't quite straightforward. So, perhaps introduce the value() function which doesn't do any type casting and enhance the intval(), strval() and floatval() functions to act like value() but cast appropriately unless the default arg is returned. To retain backward compatibility the intval() function's default arg would have to be after the optional base arg. -Rasmus

Curt Zirzow

22 years ago
* Thus wrote Rasmus Lerdorf:
> > So, perhaps introduce the value() function which doesn't do any type > casting and enhance the intval(), strval() and floatval() functions to act > like value() but cast appropriately unless the default arg is returned. > To retain backward compatibility the intval() function's default arg would > have to be after the optional base arg.
If this route is taken, what about using the name nullval() to make it fit into the naming schema? The prefix null implying no casting will occur. Going on the assumption: unset($var); echo intval($var); // 0 echo strval($var); // "" echo floatval($var); //0.00 echo nullval($var); //null $var = 1; echo intval($var); // 1 echo strval($var); // "1" echo floatval($var); //1.00 echo nullval($var); // 1 or $var = "1"; echo nullval($var); // "1" Although, i think that the intval()'s base option complicates things a little. 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!

John Coggeshall

22 years ago
Not to bust everyone's bubble here, but frankly what is the point of a 90-100+ thread on this? I mean can't this just be implemented as a PHP function without all this discussion? Coogle.
-- -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=- John Coggeshall http://www.coggeshall.org/ The PHP Developer's Handbook http://www.php-handbook.com/ -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=-

Adam Maccabee Trachtenberg

22 years ago
On Mon, 12 Jul 2004, John Coggeshall wrote:
> Not to bust everyone's bubble here, but frankly what is the point of a > 90-100+ thread on this? I mean can't this just be implemented as a PHP > function without all this discussion?
Maybe we should name the function bikeshed()? :) http://www.unixguide.net/freebsd/faq/16.19.shtml -adam
-- adam@trachtenberg.com author of o'reilly's "upgrading to php 5" and "php cookbook" avoid the holiday rush, buy your copies today!

Jason Garber

22 years ago
Hello Marc, MR> I don't think a function named param() really fits, but I do like the MR> idea of adding a type check (or in the case of PHP a type cast) to the MR> function. MR> $level = (int) (isset($_SESSION['level']) ? $_SESSION['level'] : MR> (isset($_REQUEST['level']) ? $_REQUEST['level'] : 1)) MR> becomes MR> $level = value($_SESSION['level'], $_REQUEST['level'], 1, INT); MR> Of course, I have no idea how feasible this is. MR> Marc The concept is desirable, but can be achieved if you need it just as simply using already available syntax (ie a cast): $level = (integer) value($_SESSION['level'], 1);
-- Best regards, Jason mailto:jason@ionzoft.com

Rasmus Lerdorf

22 years ago
On Sun, 11 Jul 2004, Jason Garber wrote:
> The concept is desirable, but can be achieved if you need it just as > simply using already available syntax (ie a cast): > > $level = (integer) value($_SESSION['level'], 1);
The problem with that is this: $level = (int) value($_SESSION['level'); Assume there is no level entry in the session array. This then effectively becomes: $level = (int) NULL; Guess what that gives you? Obviously not what we want here which is why we are talking about a mechanism to not cast that default value whether it be the unspecified NULL default, or whatever default is passed in. -Rasmus

Jason Garber

22 years ago
Sunday, July 11, 2004, 10:48:06 PM, you wrote: RL> On Sun, 11 Jul 2004, Jason Garber wrote:
>> The concept is desirable, but can be achieved if you need it just as >> simply using already available syntax (ie a cast): >> >> $level = (integer) value($_SESSION['level'], 1);
RL> The problem with that is this: RL> $level = (int) value($_SESSION['level'); RL> Assume there is no level entry in the session array. This then RL> effectively becomes: RL> $level = (int) NULL; RL> Guess what that gives you? Obviously not what we want here which is why RL> we are talking about a mechanism to not cast that default value whether it RL> be the unspecified NULL default, or whatever default is passed in. What would be the point of casting something unless it was null? You still have to do a type-check on the resultant value before you used it for anything useful. It seems that in this case, reverting to the ternary operator or the good old if() statement may be appropriate. ------ Before ------ $level = value($_SESSION['level'], NULL, INT); if(is_null($level) { //Initialize $level } ------ After ------ if(isset($_SESSION['level']) { $level = (integer) $_SESSION['level']; } else { //Initialize $level } I don't mean to be argumentative, but I'm just looking for a application of what you said, as one is not coming to mind. Thanks! Jason

Marc Richards

22 years ago
Jason Garber wrote:
> Sunday, July 11, 2004, 10:48:06 PM, you wrote: > RL> On Sun, 11 Jul 2004, Jason Garber wrote: > >>>The concept is desirable, but can be achieved if you need it just as >>>simply using already available syntax (ie a cast): >>> >>>$level = (integer) value($_SESSION['level'], 1); > > > RL> The problem with that is this: > > RL> $level = (int) value($_SESSION['level'); > > RL> Assume there is no level entry in the session array. This then > RL> effectively becomes: > > RL> $level = (int) NULL; > > RL> Guess what that gives you? Obviously not what we want here which is why > RL> we are talking about a mechanism to not cast that default value whether it > RL> be the unspecified NULL default, or whatever default is passed in. > > What would be the point of casting something unless it was null? You > still have to do a type-check on the resultant value before you used > it for anything useful. It seems that in this case, reverting to the > ternary operator or the good old if() statement may be appropriate. > > ------ Before ------ > > $level = value($_SESSION['level'], NULL, INT); > > if(is_null($level) > { > //Initialize $level > } > > ------ After ------ > > if(isset($_SESSION['level']) > { > $level = (integer) $_SESSION['level']; > } > else > { > //Initialize $level > } > > > I don't mean to be argumentative, but I'm just looking for a > application of what you said, as one is not coming to mind.
$level = value($_POST['level'], NULL, INT); switch($level){ case 0: echo "Welcome to level 0"; break; case 1: echo "Welcome to level 1"; break; case 2: echo "Welcome to level 2"; break; default: echo "That level is invalid. Aborting"; /* $level == null or $level
> 2 */
}

Jason Garber

22 years ago
MR> $level = value($_POST['level'], NULL, INT); MR> switch($level){ MR> case 0: MR> echo "Welcome to level 0"; MR> break; MR> case 1: MR> echo "Welcome to level 1"; MR> break; MR> case 2: MR> echo "Welcome to level 2"; MR> break; MR> default: MR> echo "That level is invalid. Aborting"; /* $level == null or $level
>> 2 */
MR> } This does not in any way call for a cast exception, it can easily be rewritten as: $level = (integer) value($_POST['level'], -1); switch($level){ case 0: echo "Welcome to level 0"; break; case 1: echo "Welcome to level 1"; break; case 2: echo "Welcome to level 2"; break; default: echo "That level is invalid. Aborting"; /* $level == -1 or $level > 2 } Don't get me wrong, an third parameter that specified a cast would not hurt (in the way I see it being mainly used): $x = (int) value($_GET['x'], 0); $x = value($_GET['x'], 0, INT); Not much different. I'm just saying that it should not be added if the same thing can be accomplished with the same effort with existing syntax. If a *frequent* use can be demonstrated for it, then I'd be all for it. Just my thoughts, thanks for reading.
-- Best regards, Jason mailto:jason@ionzoft.com

Marcus Börger

22 years ago
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" "(" <variable> [ "," <expression> ] ")"
> 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" "(" <expr> ( "," <expr> )* ")"
> 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" "(" <expr> ( "," <expr> )* ")"
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

Rasmus Lerdorf

22 years ago
On Sun, 11 Jul 2004, Marcus Boerger wrote:
> $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

Sterling Hughes

22 years ago
On Sun, 11 Jul 2004 09:43:51 -0700 (PDT), Rasmus Lerdorf <rasmus@php.net> wrote:
> On Sun, 11 Jul 2004, Marcus Boerger wrote: > > > $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);
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

Curt Zirzow

22 years ago
* Thus wrote Rasmus Lerdorf:
> On Sun, 11 Jul 2004, Marcus Boerger wrote: > > > $a = ifsetor($_GET['index'], $default); > > 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!

Johannes Schlueter

22 years ago
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

Jason Garber

22 years ago
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

Andi Gutmans

22 years ago
How about default($var, expr)? Andi At 09:43 AM 7/11/2004 -0700, Rasmus Lerdorf wrote:

Jason Garber

22 years ago
AG> How about default($var, expr)? I like it. -Jason

Sebastian Bergmann

22 years ago
Andi Gutmans wrote:
> How about default($var, expr)?
It might be a good idea to decide on a name for the construct before the PHP 5.0.0 release in order to make it a reserved word (marked for future use).
-- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/

Derick Rethans

22 years ago
On Mon, 12 Jul 2004, Sebastian Bergmann wrote:
> Andi Gutmans wrote: > > How about default($var, expr)? > > It might be a good idea to decide on a name for the construct before > the PHP 5.0.0 release in order to make it a reserved word (marked for > future use).
Agreed, and I also like default() Derick

Marcus Börger

22 years ago
Hello Derick, Monday, July 12, 2004, 11:21:06 AM, you wrote:
> On Mon, 12 Jul 2004, Sebastian Bergmann wrote:
>> Andi Gutmans wrote: >> > How about default($var, expr)? >> >> It might be a good idea to decide on a name for the construct before >> the PHP 5.0.0 release in order to make it a reserved word (marked for >> future use).
> Agreed, and I also like default()
The problem with default() is that there will be tons of scripts out there that will be broken by this. Hence i'd like to see a more non intuitive name (like the ifsetor). Probably getvalue() was the best compromise so far. Best regards, Marcus mailto:helly@php.net

George Schlossnagle

22 years ago
On Jul 12, 2004, at 11:37 AM, Marcus Boerger wrote:
> Hello Derick, > > Monday, July 12, 2004, 11:21:06 AM, you wrote: > >> Agreed, and I also like default() > > The problem with default() is that there will be tons of scripts out > there > that will be broken by this. Hence i'd like to see a more non intuitive > name (like the ifsetor). Probably getvalue() was the best compromise so > far.
what was wrong with nvl() (of oracle fame)? George

Jason Garber

22 years ago
>> >> The problem with default() is that there will be tons of scripts out >> there >> that will be broken by this. Hence i'd like to see a more non intuitive >> name (like the ifsetor). Probably getvalue() was the best compromise so >> far.
GS> what was wrong with nvl() (of oracle fame)? ifset() ifsetor() setor() are 3 short, "construct" sounding, meaningful names to consider (they have all been mentioned before). -Jason

Marcus Börger

22 years ago
Hello George, Monday, July 12, 2004, 6:36:22 PM, you wrote:
> On Jul 12, 2004, at 11:37 AM, Marcus Boerger wrote:
>> Hello Derick, >> >> Monday, July 12, 2004, 11:21:06 AM, you wrote: >> >>> Agreed, and I also like default() >> >> The problem with default() is that there will be tons of scripts out >> there >> that will be broken by this. Hence i'd like to see a more non intuitive >> name (like the ifsetor). Probably getvalue() was the best compromise so >> far.
> what was wrong with nvl() (of oracle fame)?
In oracle it means Null-VaLue replacement. But we are providing a default in case a variable is not set. But anyway from my side this would give a good name, too (for No-VaLue) in the same manner coalesce would work for the other behavior mentioned in this thread. Best regards, Marcus mailto:helly@php.net

Derick Rethans

22 years ago
On Mon, 12 Jul 2004, George Schlossnagle wrote:
> what was wrong with nvl() (of oracle fame)?
Nobody else but oracle people have any idea what they expect when they see nvl(). Derick

Antony Dovgal

22 years ago
On Tue, 13 Jul 2004 09:12:19 +0200 (CEST) Derick Rethans <derick@php.net> wrote:
> On Mon, 12 Jul 2004, George Schlossnagle wrote: > > > what was wrong with nvl() (of oracle fame)? > > Nobody else but oracle people have any idea what they expect when they > see nvl().
Agree. Moreover, it's too obscure to understand. I vote for default() or default_value(). (Actually I vote against such construct at all, but it seems that nobody listens to such votes). --- WBR, Antony Dovgal aka tony2001 tony2001@phpclub.net || antony@dovgal.com

Andi Gutmans

22 years ago
It's a reserved word so I doubt it'll break scripts. Andi At 05:37 PM 7/12/2004 +0200, Marcus Boerger wrote:

Marcus Börger

22 years ago
Hello Andi, wow i didn't remember seeing that. So with default being a reserved word to me it seems like one of the best choices. Monday, July 12, 2004, 10:01:47 PM, you wrote:
> It's a reserved word so I doubt it'll break scripts.
> Andi
> At 05:37 PM 7/12/2004 +0200, Marcus Boerger wrote: >>Hello Derick, >> >>Monday, July 12, 2004, 11:21:06 AM, you wrote: >> >> > On Mon, 12 Jul 2004, Sebastian Bergmann wrote: >> >> >> Andi Gutmans wrote: >> >> > How about default($var, expr)? >> >> >> >> It might be a good idea to decide on a name for the construct before >> >> the PHP 5.0.0 release in order to make it a reserved word (marked for >> >> future use). >> >> > Agreed, and I also like default() >> >>The problem with default() is that there will be tons of scripts out there >>that will be broken by this. Hence i'd like to see a more non intuitive >>name (like the ifsetor). Probably getvalue() was the best compromise so >>far.
-- Best regards, Marcus mailto:helly@php.net

l0t3k

22 years ago
"Andi Gutmans" <andi@zend.com> wrote in message news:5.1.0.14.2.20040711205308.033261e8@127.0.0.1...
> How about default($var, expr)?
my only reservation is that "default" is already part of a language construct : <code> switch ($param = $_GET["param"]) { case "foo" : bar(); break; case "this" : that(); break; default: the_other( default($param) ); } </code> i'd say use defaultvalue

Derick Rethans

22 years ago
On Mon, 12 Jul 2004, l0t3k wrote:
> > "Andi Gutmans" <andi@zend.com> wrote in message > news:5.1.0.14.2.20040711205308.033261e8@127.0.0.1... > > How about default($var, expr)? > my only reservation is that "default" is already part of a language > construct :
...
> i'd say use defaultvalue
Too long IMO. Derick

Bert Slagter

22 years ago
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