On 29 October 2005 22:56, Greg Beaver wrote:
For an operation as complicated as use the first variable
that exists
I would be most comfortable with:
$d = first-existing: $a, $b, $c;
That's a horrible syntax, but a fantastic name for a language construct to do
the job. Even better might
What about a similar construct for checking truth? eg,
$foo = first_true($bar, $baz, $bang);
returns the value of the first variable that passes the if(isset($var)
!empty($var)) test.
On 10/31/05, Ford, Mike [EMAIL PROTECTED] wrote:
On 29 October 2005 22:56, Greg Beaver wrote:
For an
I'm a big fan of coalesce($param1, $param2, ..., $paramN) (or firstset()).
The syntax allows for more than what ifsetor($var, $value) would do.
Ifsetor() could be done in userspace, but I don't see how coalesce() could,
because of the variable number of parameters.
Ron
Sean Coates [EMAIL
Whatever the name is, I think the most important thing should be that
second argument is not evaluated if the first one is set.
And about the name - $a = $b ?? $c looks good. $a ??= $c is fine too
because it is close to $a = $b || $c and $a ||= $c..
On 30/10/05, Ron Korving [EMAIL PROTECTED]
Hello Ron,
damn it! ifsetor or any equivalent cannot be done in userspace. If you
don't get don't write here.
marcus
Sunday, October 30, 2005, 9:52:47 AM, you wrote:
I'm a big fan of coalesce($param1, $param2, ..., $paramN) (or firstset()).
The syntax allows for more than what
Marcus, my point was that this simple function:
function ifsetor($var, $value)
{
return (isset($var)) ? $var : $value;
}
can be done in userspace, and that a coalesce() like function will have the
added benefit of a variable number of parameters, which as far as I know,
cannot be done
function ifsetor($var, $value)
{
return (isset($var)) ? $var : $value;
}
can be done in userspace.
Perhaps, but it won't do what you think, and certainly won't do what this
thread has been discussing for over half a year.
--
PHP Internals - PHP Runtime Development Mailing List
To
On Sun, 2005-10-30 at 09:52 +0100, Ron Korving wrote:
I'm a big fan of coalesce($param1, $param2, ..., $paramN) (or firstset()).
The syntax allows for more than what ifsetor($var, $value) would do.
Ifsetor() could be done in userspace, but I don't see how coalesce() could,
because of the
On Sat, 29 Oct 2005, Sara Golemon wrote:
How about ||| and |||= ?
How about a good ol' beating with a large trout? :)
--Jani
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
The function I used in my post does not generate an E_NOTICE, because a
call-by-reference can be done with an unset variable (that can be set from
the function).
?php
error_reporting(E_ALL);
function ifsetor($var, $value)
{
return (isset($var)) ? $var : $value;
}
echo
On Sun, 2005-10-30 at 15:57, Ron Korving wrote:
The function I used in my post does not generate an E_NOTICE, because a
call-by-reference can be done with an unset variable (that can be set from
the function).
?php
error_reporting(E_ALL);
function ifsetor($var, $value)
{
A good point certainly... I suppose it could continue to follow the
current form, evaluating $c as false and return int(1) instead of
bool(true). Though that would probably diminish it's utility for 'if set
or'. And there would be a BC break for those doing:
$a = $b || $c;
if ($a === true) {
A good point certainly... I suppose it could continue to follow the
current form, evaluating $c as false and return int(1) instead of
bool(true). Though that would probably diminish it's utility for 'if set
or'. And there would be a BC break for those doing:
$a = $b || $c;
if ($a === true) {
}
However, in terms of precedents, there are the combined assignment
operators such as =, +=, .=, and so on. They would suggest that
$a ||= $b;
should be equivalent to
$a = $a || $b;
So I don't think ||= in the suggested usage is intuitive. And adding
strange automagical meanings to $a = $a ||
Evaluating an idea based on it's syntactic similarities to other
languages is complete and utter nonsense. It has nothing to with being
like language Xyz. It has to do with familiarity to language constructs.
One already understands the idea of 'this || that'. It's certainly
I'll throw the
On Sat, 2005-10-29 at 14:07 -0700, Sara Golemon wrote:
Evaluating an idea based on it's syntactic similarities to other
languages is complete and utter nonsense. It has nothing to with being
like language Xyz. It has to do with familiarity to language constructs.
One already understands
Hello Jasper,
Saturday, October 29, 2005, 11:34:52 PM, you wrote:
On Sat, 2005-10-29 at 14:07 -0700, Sara Golemon wrote:
Evaluating an idea based on it's syntactic similarities to other
languages is complete and utter nonsense. It has nothing to with being
like language Xyz. It has to do
Sara Golemon wrote:
Evaluating an idea based on it's syntactic similarities to other
languages is complete and utter nonsense. It has nothing to with being
like language Xyz. It has to do with familiarity to language constructs.
One already understands the idea of 'this || that'. It's
I still think // and //= would be the most reasonable. They involve
the least amount of syntax and // looks similar to ||
On 10/29/05, Greg Beaver [EMAIL PROTECTED] wrote:
Sara Golemon wrote:
Evaluating an idea based on it's syntactic similarities to other
languages is complete and utter
Sebastian wrote:
I still think // and //= would be the most reasonable. They involve
the least amount of syntax and // looks similar to ||
// is a comment. Why don't you guys at least take a peek at the grammar
before suggesting stuff.
-Rasmus
--
PHP Internals - PHP Runtime Development
You are joking, aren't you?
- David
-Original Message-
From: Sebastian [mailto:[EMAIL PROTECTED]
Sent: Sunday, October 30, 2005 12:43 AM
To: Greg Beaver
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] what happened to that new isset() like language
I still think
: Re: [PHP-DEV] what happened to that new isset() like language
I still think // and //= would be the most reasonable. They involve
the least amount of syntax and // looks similar to ||
On 10/29/05, Greg Beaver [EMAIL PROTECTED] wrote:
Sara Golemon wrote:
Evaluating an idea based
Hi!
If you want something similar why not something that's similar to the
currently used $x = isset($x) ? $x :'x';. I don't think PHP has
something that can be written as ?? currently and it would be similar
to the current expression: $x = $x ?? 'x'; or $x ??= 'x'; Or if it
should be a
Given that // is not acceptable, as others sarcastically reminded me,
and that this introduces new sytax, I think it might be best just to
add more functions. I don't think something like
$d = first-existing: $a, $b, $c;
is any better than first_existing($a, $b, $c), and the former happens
at
For the assign-if-not-set operator, I like the idea of:
$foo ?= 'bar';
? implies a condition, and the = immediately following will raise a parse
error in older versions.
There's admittedly potential for confusion with the ternary operator, but
since that's most commonly used for conditional
But what about the use of ? as an infix operator? that wouldn't work
out so well because of the ternary ?:
On 10/29/05, Arpad Ray [EMAIL PROTECTED] wrote:
For the assign-if-not-set operator, I like the idea of:
$foo ?= 'bar';
? implies a condition, and the = immediately following will raise
Sebastian wrote:
Given that // is not acceptable, as others sarcastically reminded me,
and that this introduces new sytax, I think it might be best just to
add more functions. I don't think something like
$d = first-existing: $a, $b, $c;
is any better than first_existing($a, $b, $c),
Sebastian wrote:
But what about the use of ? as an infix operator? that wouldn't work
out so well because of the ternary ?:
Right, which is why I didn't suggest that.
I think Greg's idea of first-existing: is an interesting one (and by the sound
of it the most robust).
Personally I'd like
Hello Edin,
on the other hand it is not doablenot without a major slowdown.
Thus the idea of ifsetor($var, expression).
Why the hell do we need to discuss this over and over again?
The only way is this version. Be it with some cryptic operator like
'?:' or some function name like 'ifsetor'.
Silva
-Original Message-
From: Edin Kadribasic [mailto:[EMAIL PROTECTED]
Sent: Saturday, October 29, 2005 4:19 PM
To: Sebastian
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] what happened to that new isset() like language
If we're going to add a new language construct I believe
Bob Silva wrote:
This makes perfect sense (to me at least):
$localvar = isset($_REQUEST['globalvar'], default value 1, ...);
The obvious problem there being that isset() currently takes multiple
variables as arguments and checks that they're all set. From the manual:
bool isset ( mixed var
Bob Silva wrote:
It should be a function and not a language construct IMHO. Either ifsetor or
overload the isset statement (which may not be possible within the engine).
It _has_ to be a language construct, and not a function (otherwise, we'd
get a notice when first using the variable).
It
: Saturday, October 29, 2005 6:17 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] what happened to that new isset() like language
Bob Silva wrote:
This makes perfect sense (to me at least):
$localvar = isset($_REQUEST['globalvar'], default value 1, ...);
The obvious problem
Andi Gutmans wrote:
I don't think it's a matter of giving the engine a try. I think we first need
to make a decision what the best way to go is and then we can discuss
implementation if/what is possible. Once 5.0.0 is out I'm going to have more
time look into this.
What's the word on this?
Wow, it'll be just like perl! this is so great.
On 10/28/05, James Crumpton [EMAIL PROTECTED] wrote:
Andi Gutmans wrote:
I don't think it's a matter of giving the engine a try. I think we first
need
to make a decision what the best way to go is and then we can discuss
implementation
Evaluating an idea based on it's syntactic similarities to other languages is
complete and utter nonsense. It has nothing to with being like language Xyz. It
has to do with familiarity to language constructs. One already understands the
idea of 'this || that'. It's certainly doesn't take a
James Crumpton wrote:
Evaluating an idea based on it's syntactic similarities to other
languages is complete and utter nonsense. It has nothing to with being
like language Xyz. It has to do with familiarity to language constructs.
One already understands the idea of 'this || that'. It's
Adam Maccabee Trachtenberg wrote:
On Thu, 8 Jul 2004, Marc Richards wrote:
Are you saying PHP will never introduce an operator that doesn't already
exist in a large number of other languages?
I certainly hope not. (Well, I guess === and !=== are exceptions to
this statement.)
Compound Ternary
On Fri, 9 Jul 2004, Rasmus Lerdorf wrote:
On Thu, 8 Jul 2004, Marc Richards wrote:
Are you saying PHP will never introduce an operator that doesn't already
exist in a large number of other languages?
That's a good rule. Over the 10 years of PHP development we have followed
this with
Andi Gutmans wrote:
I don't think it's a matter of giving the engine a try. I think we first
need to make a decision what the best way to go is and then we can
discuss implementation if/what is possible. Once 5.0.0 is out I'm going
Thanks for these words of wisdom, Andi.
Dismissing a solution
Sascha Schumann wrote:
This rule would favor the a ? : b notation - which has
been supported by GCC for at least five years.
My personal reasons against ?: :
- It's non-standard and not well known even though GCC supports it.
- It's hard to look up.
- It's easily confused with $a ? $b :
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:
Andi Gutmans wrote:
Personally I am not that fond of
Hello Christian,
Saturday, July 10, 2004, 10:35:38 AM, you wrote:
Andi Gutmans wrote:
I don't think it's a matter of giving the engine a try. I think we first
need to make a decision what the best way to go is and then we can
discuss implementation if/what is possible. Once 5.0.0 is out
Hello Christian,
Saturday, July 10, 2004, 10:46:51 AM, you wrote:
Sascha Schumann wrote:
This rule would favor the a ? : b notation - which has
been supported by GCC for at least five years.
My personal reasons against ?: :
- It's non-standard and not well known even though GCC
This rule would favor the a ? : b notation - which has
been supported by GCC for at least five years.
My personal reasons against ?: :
- It's non-standard and not well known even though GCC supports it.
- It's hard to look up.
- It's easily confused with $a ? $b : $c;
- It's ugly (-:C
* Thus wrote Marc Richards:
Jason Garber wrote:
I am interested in the new construct for the exact same reason, E_ALL
development. I am intersted in the ?: operator because it looks alot
simpler, especially if you want to chain them together:
$user = $_SESSION['user] ?:
Hello Marc,
Friday, July 9, 2004, 1:33:02 AM, you wrote:
Rasmus Lerdorf wrote:
On Thu, 8 Jul 2004, Marc Richards wrote:
Rasmus Lerdorf wrote:
On Thu, 8 Jul 2004, Marc Richards wrote:
Does it? There are other similar constructs that don't e.g. +=, $a ? $b
: $c, .=;
These have roots
Hello Daniel,
Friday, July 9, 2004, 4:33:42 AM, you wrote:
Why not just call it the issetor, or the setor operator?
That's the point here. How shall we call the new operator.
--
Best regards,
Marcusmailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime
On Thu, 8 Jul 2004, Marc Richards wrote:
Right. Sorry. I meant.
$a = isset($b) ? $b : $c;
But my point is that you won't be FORCED to use the new operator, just
like you aren't FORCED to use +=.
I think it simply boils down to this:
- PHP *developers* want a function for it.
regards,
On Fri, 2004-07-09 at 02:49, Marcus Boerger wrote:
Hello Daniel,
Friday, July 9, 2004, 4:33:42 AM, you wrote:
Why not just call it the issetor, or the setor operator?
That's the point here. How shall we call the new operator.
I'm +1 on the coalesce name since I even think having the
Hi,
I would suggest another name for ifsetor.
In relational databases, there is a similar function, called NVL in oracle,
and
IFNULL in MySQL and coalesce in postgresql for testing for null, and
returning
a default value if the variable is null.
I think ifsetor sounds a big ugly. I would
To be honest I am kinda hot and cold about how close it is to the
ternary operator. On the one hand the two could be easily confused, but
on the other hand they are in fact very similar in function in which
case we could market (meaning document) them as being related.
Ternary operator:
Marcus, or anyone else familiar enough with the engine,
Just to clarify, do you see an inherent technical problem with nesting
ifsetor() function calls?
$user = ifsetor($_SESSION['user'], ifsetor($_POST['user'], NULL));
or is the problem only with accepting a list of parameters:
$user =
On Thu, 8 Jul 2004, Marc Richards wrote:
Are you saying PHP will never introduce an operator that doesn't already
exist in a large number of other languages?
That's a good rule. Over the 10 years of PHP development we have followed
this with the only exception being the === operators for
On Jul 9, 2004, at 2:55 PM, Rasmus Lerdorf wrote:
On Thu, 8 Jul 2004, Marc Richards wrote:
Are you saying PHP will never introduce an operator that doesn't
already
exist in a large number of other languages?
That's a good rule. Over the 10 years of PHP development we have
followed
this with the
Isn't this problem solvable with just a User Space function?
?php
error_reporting(E_ALL);
function ifsetor($variable, $alternate = NULL){
if(isset($variable)){
$tmp = $variable;
echo('p$variable exists./p');
}
else{
$tmp =
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Cris H wrote:
| Isn't this problem solvable with just a User Space function?
[snip]
| Because, as Derick Rethans mentioned, arguments passed by
| reference will not trigger the Undefined (variable | index)
| Notice at the point of the function call,
That would satisfy some of the requested feature, but try
calling ifsetor($my_array['bad key'], functionWithSideEffects()).
Marcus has repeatedly mentioned that the requested feature is
hard (bordering on impossible) to implement, but in the requested
feature (if I understand it (and it is what I
That would satisfy some of the requested feature, but try
calling ifsetor($my_array['bad key'],
functionWithSideEffects()).
That could be circumvented (somewhat hackishly, I concede) by
recoding a new function and passing the second arg as the string
functionWithSideEffects and using the
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:
Hello Marc,
Thursday, July 8, 2004, 11:54:59 PM, you wrote:
Marcus Boerger wrote:
?: would require a default value. ifsetor() allows to
Hello Robert,
coalesce would be:
coalesce ( var ( , var )* [ , expr ] )
and would also require heay engine patching. I am speaking of a
really major change here, i already looked into what it would
need month's ago. Since the operator i proposed is different from
the coalesce functionality
Hello John,
we are not testing against NULL here. We check for existance.
That would be having a uniform sql way to test the existance of
a table or column in a table. Hence IFNULL(), NOT IFNULL(),
NVL() are different. I also explained several times why coalesce
doesn't apply.
Friday, July 9,
Hello George,
Friday, July 9, 2004, 8:56:15 PM, you wrote:
On Jul 9, 2004, at 2:55 PM, Rasmus Lerdorf wrote:
On Thu, 8 Jul 2004, Marc Richards wrote:
Are you saying PHP will never introduce an operator that doesn't
already
exist in a large number of other languages?
That's a good rule.
I don't think it's a matter of giving the engine a try. I think we first
need to make a decision what the best way to go is and then we can discuss
implementation if/what is possible. Once 5.0.0 is out I'm going to have
more time look into this.
At 01:54 AM 7/10/2004 +0200, Marcus Boerger
On Fri, 2004-07-09 at 19:54, Marcus Boerger wrote:
Hello Robert,
coalesce would be:
coalesce ( var ( , var )* [ , expr ] )
and would also require heay engine patching. I am speaking of a
really major change here, i already looked into what it would
need month's ago. Since the
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);
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 operatorif you can collect all the ideas or can come up with ther
perfect one!?!
Well I'm partial to ?: and
Jason Garber wrote:
What we basically settled on was to use this syntax (as a new language
construct):
$x = ifsetor(mixed variable, mixed default);
Before it gets forgotten: I still think that
$x = ifsetor(mixed var, mixed var [, ...]);
with expressions in all parts is the way to go.
Example
Christian Schneider wrote:
Before it gets forgotten: I still think that
$x = ifsetor(mixed var, mixed var [, ...]);
with expressions in all parts is the way to go.
Example usage:
$a = ifsetor($_REQUEST['x'], $db-get('x'), 'default_x');
The other syntax could work for that as well...
$a =
On Thu, 8 Jul 2004, Marc Richards wrote:
Christian Schneider wrote:
Before it gets forgotten: I still think that
$x = ifsetor(mixed var, mixed var [, ...]);
with expressions in all parts is the way to go.
Example usage:
$a = ifsetor($_REQUEST['x'], $db-get('x'), 'default_x');
Christian Schneider [EMAIL PROTECTED] writes:
Before it gets forgotten: I still think that
$x = ifsetor(mixed var, mixed var [, ...]);
with expressions in all parts is the way to go.
Example usage:
$a = ifsetor($_REQUEST['x'], $db-get('x'), 'default_x');
And I also think that the name
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 operatorif you can collect all the ideas
Hello Christian,
Thursday, July 8, 2004, 5:13:36 PM, you wrote:
Jason Garber wrote:
What we basically settled on was to use this syntax (as a new language
construct):
$x = ifsetor(mixed variable, mixed default);
Before it gets forgotten: I still think that
$x = ifsetor(mixed var, mixed
Marcus Boerger wrote:
As i wrote before several times before to me this seems impossible. But
maybe someone can come up with a working patch?
I'll have a look at it as soon as I find time (not this week anyway).
What I'm looking for is the equivalent of
coalesce($a, $b) == @($a ? $a : b)
or
Rasmus Lerdorf wrote:
On Thu, 8 Jul 2004, Marc Richards wrote:
Christian Schneider wrote:
Before it gets forgotten: I still think that
$x = ifsetor(mixed var, mixed var [, ...]);
with expressions in all parts is the way to go.
Example usage:
$a = ifsetor($_REQUEST['x'], $db-get('x'),
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
On Thu, 8 Jul 2004, Marc Richards wrote:
Does it? There are other similar constructs that don't e.g. +=, $a ? $b
: $c, .=;
These have roots in other languages and as such have a familiarity to
them. ?: would be a brand new operator nobody has seen before and one
that looks a lot like the
Rasmus Lerdorf wrote:
On Thu, 8 Jul 2004, Marc Richards wrote:
Does it? There are other similar constructs that don't e.g. +=, $a ? $b
: $c, .=;
These have roots in other languages and as such have a familiarity to
them. ?: would be a brand new operator nobody has seen before and one
that
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
On Thu, 8 Jul 2004, Marc Richards wrote:
Rasmus Lerdorf wrote:
On Thu, 8 Jul 2004, Marc Richards wrote:
Does it? There are other similar constructs that don't e.g. +=, $a ? $b
: $c, .=;
These have roots in other languages and as such have a familiarity to
them. ?: would be a
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
Marc Richards wrote:
What? Why? There is obviously a way around it, because that is what
people are using now.
$a = $b ? $b : $c;
If $b is not set, it will throw notices.
The correct way is something similar to:
$a = (!isset($b) !isnull($b)) ? $b : $c
Which defeats the whole reason of
Olivier Hill wrote:
Marc Richards wrote:
What? Why? There is obviously a way around it, because that is what
people are using now.
$a = $b ? $b : $c;
If $b is not set, it will throw notices.
The correct way is something similar to:
$a = (!isset($b) !isnull($b)) ? $b : $c
Right. Sorry. I
On Thu, 8 Jul 2004, Marc Richards wrote:
Are you saying PHP will never introduce an operator that doesn't already
exist in a large number of other languages?
I certainly hope not. (Well, I guess === and !=== are exceptions to
this statement.)
Compound Ternary operator:
$a = $b ?: $c;
You
Jason Garber wrote:
The original reason that I asked for this functionality was to make it
significantly easier to work with E_ALL error reporting. When I say
easier, I mean by reducing duplicate code.
//This
$foo = (integer) ifsetor($_POST['foo'], 0);
//Instead of
$foo = (integer)
Adam Maccabee Trachtenberg wrote:
On Thu, 8 Jul 2004, Marc Richards wrote:
Compound Ternary operator:
$a = $b ?: $c;
You realize that ternary means it takes three arguments? It has
nothing to do with question marks and colons. Your new compound
ternary operator is really a binary operator.
Good
Hi Marc,
To be honest, I don't care at this point. As long as we have something
implemented in 5.1 for allowing PHP users to simplify working in E_ALL
error mode.
This thing:
a) it has to base it's decision on the same logic isset() uses
b) it should not evaluate the second part unless it is
Marc Richards wrote:
They won't. Not until they hear about it or read about it. But that is
true whether it is a function or and operator. Making it a function
won't make everyone magically cogniscent of it. Of course it will be
important to make it easy to search for information about it
Oh baby, oh baby. I was undecided (and really just didn't care about it
either way) but when Marc put it this way (see the bottom line there) I was
sold. That's just sexy.
-Dan, who perhaps gets a bit *too* into this sort of thing...
I am interested in the new construct for the exact same
Why not just call it the issetor, or the setor operator? Also, why does
www.php.net/ternary not link to what one would assume it might link to? We
could do the same with www.php.net/setor.
Dan
But the fact still remains that if we did go with
this syntax, we could and probably should find a
Hi Marc,
What we basically settled on was to use this syntax (as a new language
construct):
$x = ifsetor(mixed variable, mixed default);
If I recall correctly, Marcus had a patch that implemented it and it was
going to be plugged in in the 4.1 branch (when it is created).
I'm eagerly waiting
Jason Garber wrote:
Hi Marc,
What we basically settled on was to use this syntax (as a new language
construct):
$x = ifsetor(mixed variable, mixed default);
So ?: is out then? Or just delayed until it can be tackled.
If I recall correctly, Marcus had a patch that implemented it and it was
Hi Marc,
At 7/7/2004 09:06 PM -0400, Marc Richards wrote:
Jason Garber wrote:
Hi Marc,
What we basically settled on was to use this syntax (as a new language
construct):
$x = ifsetor(mixed variable, mixed default);
So ?: is out then? Or just delayed until it can be tackled.
Who am I to say it's
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 operatorif you can collect all the ideas or can come up with ther
perfect one!?!
a patch is here:
At 09:20 PM 7/7/2004 -0400, Jason Garber wrote:
On a related note, does anyone know when 5.1 is going to be
branched? Shortly after the 5.0.0 release, I assume.
Yeah I'd like to branch 5.0 off right away as there are some things I'd
like to start working on, mainly some performance patches.
95 matches
Mail list logo
