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
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 m
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).
>
>error_reporting(E_ALL);
>
> function ifsetor(&$var, $value)
> {
>
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).
This simply prints 'test' and shows no errors. In fact, a var_dump() on $bla
will show that it's become NULL. Never mind this whole if
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
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 va
Hi Marcus,
> ifsetor or any equivalent cannot be done in userspace.
i agree here.
Last time this topic has been discussed I've naively asked for
opinions regarding a userland implementation. Afterwards the
discussion suddenly ended.
In the meantime I've tried to use it more often but found myse
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 unsu
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
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 PROT
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 ifsetor($va
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]> wro
L PROTECTED]
> Sent: 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['g
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 c
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
ible in the engine is out of my range of knowledge.
Bob 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
Hello Edin,
on the other hand it is not doablenot without a major slowdown.
Thus the idea of ifsetor($var, ).
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'. Either way
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
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, $
If we're going to add a new language construct I believe that it should
be readable and not some perl-like thingie. SQL has coalesce() functions
which returns returns first non-null argument of any number of
arguments. PHP version could return a first set argument:
$lang = coalesce($_COOKIE['l
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
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 as
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 t
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 si
: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 // and //= would be the most reasonable. They involve
> > the least amount of syntax and // looks similar to ||
>
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 lang
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 Ma
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
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
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. I
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 und
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 water
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 || $
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) {
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 cer
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 stret
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
> > impleme
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
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 op
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
Ye
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
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
Hello Robert,
Saturday, July 10, 2004, 3:12:09 AM, you wrote:
> On Fri, 2004-07-09 at 19:54, Marcus Boerger wrote:
>> Hello Robert,
>>
>> coalesce would be:
>>
>> "coalesce" "(" ( "," )* [ "," ] ")"
>>
>> and would also require heay engine patching. I am speaking of a
>> really major chan
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 ifs
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 : $
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 be
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
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);
On Fri, 2004-07-09 at 19:54, Marcus Boerger wrote:
> Hello Robert,
>
> coalesce would be:
>
> "coalesce" "(" ( "," )* [ "," ] ")"
>
> 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
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 wrote
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
Hello Marc,
you can use my patch to test
The second parameter can be any expression. Hence another
ifsetor() should be possible (if not we'd fix that).
marcus
Friday, July 9, 2004, 8:48:12 PM, you wrote:
> Marcus, or anyone else familiar enough with the engine,
> Just to clarify, do you
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, 20
Hello Robert,
coalesce would be:
"coalesce" "(" ( "," )* [ "," ] ")"
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 man
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
> 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
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 w
-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, a
Isn't this problem solvable with just a "User Space" function?
$variable exists.');
}
else{
$tmp = $alternate;
echo('no $variable here.');
}
return $tmp;
}
// no errors thrown ...
$nonexistent = ifsetor($nonexistent);
if
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
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 ch
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 = ifsetor($
> 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 op
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 suggest
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 havi
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.
regard
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 Develo
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
>>>
* 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] ?:
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
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 rea
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
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 ne
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.
Goo
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) (isset($_PO
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;
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 mea
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 in other languages and as such have a familiarity to
them. ?: would
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) (isset($_POST['foo']) ? $_POST['
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 introduc
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
Olivier Hill wrote:
Marc Richards wrote:
That is true for other things as well:
$a = $b += $c += $d;
$a = $b + $c = $d;
Well.. yes and no...
If you are afraid of making mistake, you can force yourself to never use
+= -= *= operators, because you can simply write $a = $a + $b
But if PHP introduc
Marc Richards wrote:
That is true for other things as well:
$a = $b += $c += $d;
$a = $b + $c = $d;
Well.. yes and no...
If you are afraid of making mistake, you can force yourself to never use
+= -= *= operators, because you can simply write $a = $a + $b
But if PHP introduces the ?: operator, yo
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
> > the
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
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 loo
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
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 se
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'), 'default_x'
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
coalesc
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,
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 t
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
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 th
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'), 'defa
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 li
Christian Schneider wrote:
Before it gets forgotten: I still think that
$x = ifsetor(mixed var, mixed var [, ...]);
with expressions in all parts is the way to go.
Example usage:
$a = ifsetor($_REQUEST['x'], $db->get('x'), 'default_x');
The other syntax could work for that as well...
$a = $_REQUEST
Jason Garber wrote:
What we basically settled on was to use this syntax (as a new language
construct):
$x = ifsetor(mixed variable, mixed default);
Before it gets forgotten: I still think that
$x = ifsetor(mixed var, mixed var [, ...]);
with expressions in all parts is the way to go.
Example usage
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 th
1 - 100 of 106 matches
Mail list logo
