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
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
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
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
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
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
Marcus Boerger wrote:
?: would require a default value. ifsetor() allows to assume
NULLhence
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
Hello Marc,
Thursday, July 8, 2004, 11:54:59 PM, you wrote:
Marcus Boerger wrote:
?: would require a default value. ifsetor() allows to assume
NULLhence
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:
- $a = ifsetor($b)
- $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
Marcus Boerger wrote:
it would allow two versions by having the default optional:
- $a = ifsetor($b)
- $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
Ok, so let me try to do a little summary.
If and When
- There seems to be a general consensus that this feature should be
implemented in SOME way. - 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
- ?: 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)
- 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.
- 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:
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
-----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
Ilya Sher wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1firstset() 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
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
- There seems to be a general consensus that this feature should be
implemented in SOME way.- 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
- ?: 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)
- 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.
- 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
$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
>
>
> > $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
- Thus wrote Rasmus Lerdorf:
$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!
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
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
Marc Richards wrote:
- 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