On Sat, Apr 23, 2011 at 1:21 PM, Hannes Landeholm wrote:
> I was planning on replying to the "coalesce" suggestion but you really took
> my concerns and stated them much better than I could have myself, plus a
> couple of other concerns I didn't even think about.
>
> To respond to Arpad Ray's stat
I was planning on replying to the "coalesce" suggestion but you really took
my concerns and stated them much better than I could have myself, plus a
couple of other concerns I didn't even think about.
To respond to Arpad Ray's statement:
"To elaborate, I'd probably think this code was an unlikely
It's good for some situations, but there are plenty more where it doesn't cut it,
e.g. $_GET[?'foo'] $:= get_default_from_db('foo') $: "hard-coded".
Ben.
On 23/04/11 12:54 PM, Martin Scotta wrote:
what about something like this?
$_GET += array( 'key' => 42, 'other' => 'blablah' );
echo
what about something like this?
$_GET += array( 'key' => 42, 'other' => 'blablah' );
echo $_GET [ 'key' ];
and it's already available on you current instalation :)
Martin Scotta
On Fri, Apr 22, 2011 at 11:27 PM, Ben Schmidt wrote:
> On 21/04/11 9:56 AM, Arpad Ray wrote:
>
>> I must say th
What does coalesce() do?
If I'm guessing correctly, would proposal #2 that Rune Kaagaard put up
solve that for you?
https://gist.github.com/909711
Rune's proposal #2, extending func_get_arg(), is impossible to
implement/would not work.
His proposal #3, which is more like coalesce(), suffers fr
On 21/04/11 9:56 AM, Arpad Ray wrote:
I must say that the prospect of yet more new syntax is scary. It
really looks like Perl, and I wouldn't have the slightest clue what it
meant if I'd missed the release notes.
I agree it looks a little bit strange. I think that's partly a benefit:
it doesn't
>
>
> What does coalesce() do?
> If I'm guessing correctly, would proposal #2 that Rune Kaagaard put up
> solve that for you?
> https://gist.github.com/909711
>
> Cheers,
> David
>
>
It was discussed in a separate thread.
generally it would do the same as in SQL, return the first non-null value
fr
On 21/04/11 08:56, Arpad Ray wrote:
> On Thu, Apr 14, 2011 at 3:05 PM, Hannes Landeholm wrote:
>> Some suggested that the ternary if comparison should suppress the notice
>> automatically. This would break existing code and also be confusing since
>> people expect a ternary if and normal if to wor
On Thu, Apr 21, 2011 at 12:56 AM, Arpad Ray wrote:
> I've pined for something like coalesce($_GET['foo'], $defaults['foo'],
> 42) for years, and I think that style is far more in keeping with the
> PHP ethos, and far more readily understandable than this suggested new
> syntax.
>
To elaborate, I'
On Thu, Apr 14, 2011 at 3:05 PM, Hannes Landeholm wrote:
> Some suggested that the ternary if comparison should suppress the notice
> automatically. This would break existing code and also be confusing since
> people expect a ternary if and normal if to work the same way.
>
> Some suggested ?? as
On 17/04/11 9:14 AM, Ángel González wrote:
Ben Schmidt wrote:
$var = $arr['key'] ?? : 'empty';
Also note this is possible with the recent proposal Hannes and I were
discussing. It simply looks like
$var = $arr?['key'] ?: 'empty';
The ?[ avoids notices and the ?: works as it always has.
Ben.
Ben Schmidt wrote:
>>> $var = $arr['key'] ?? : 'empty';
>
> Also note this is possible with the recent proposal Hannes and I were
> discussing. It simply looks like
>
> $var = $arr?['key'] ?: 'empty';
>
> The ?[ avoids notices and the ?: works as it always has.
>
> Ben.
If it was going to be ?[, I
$var = $arr['key'] ?? : 'empty';
Also note this is possible with the recent proposal Hannes and I were
discussing. It simply looks like
$var = $arr?['key'] ?: 'empty';
The ?[ avoids notices and the ?: works as it always has.
Ben.
--
PHP Internals - PHP Runtime Development Mailing List
To
I believe describing nullness checking as a "main" issue is a rather
strong assessment.
I don't think so, obviously. :-)
$var = (isset($arr['key'])) ? $arr['key'] : 'empty';
Nullness checking is half of what that code does, isn't it? Otherwise it
would be (isset($arr['key']) && $arr['key']),
On Sat, 16 Apr 2011 03:42:11 +0200, Adam Richardson
wrote:
On Fri, Apr 15, 2011 at 8:46 PM, Ben Schmidt
wrote:
There was also my suggestion of a "checked ternary" operator [see my
previous email in this thread.] Backwards compatible, practical, and
simple.
It doesn't address the main is
On Fri, Apr 15, 2011 at 8:46 PM, Ben Schmidt
wrote:
> There was also my suggestion of a "checked ternary" operator [see my
>> previous email in this thread.] Backwards compatible, practical, and
>> simple.
>>
>
> It doesn't address the main issues of code duplication and nullness
> checking, IMHO,
There was also my suggestion of a "checked ternary" operator [see my
previous email in this thread.] Backwards compatible, practical, and simple.
It doesn't address the main issues of code duplication and nullness
checking, IMHO, so isn't a contender. Even though it's simple and
compatible, it i
That sounds fine to me, and the extension to ArrayAccess is really
clever. I agree that 'take more care' is a better way to view the array
access. It means both the array access should be more careful (to check
and avoid errors, rather than just proceed), and also the 'caller'
should be more caref
I like this - especially .7 and .8.
The $: is intuitive because it looks like a variable that doesn't contain
anything and the : specifies what comes then.
However I'd rather use the "?" character than "@" for the simple reason that
I see this as a more careful way to access an array and not as a
I agree empty() is basically useless. We already have the existing
ternary operator (and its shortcut) to do a boolean test, which is
basically the same as empty().
The way I see it, if rather than making an isset() operator that
suppresses errors and offers a default, we added both a !==null ope
Nope. I prefer to treat "invalid" or "non existing" basic types as them
being set to a default value. This makes the input handler very robust and I
don't have to waste time by writing code that handles failed validation.
For example if I read an integer from $_POST I'd simply write:
$value = \in
On Thu, 14 Apr 2011 15:25:45 +0200, Martin Scotta
wrote:
arrays are intent for holding values, not for represent things so use
objects for that.
the need for array_key_exists/isset to check for the presence of an
index is
a smell that you need to refactor your code for a different datatype
On Thu, 14 Apr 2011 16:05:45 +0200, Hannes Landeholm
wrote:
So basically the discussion now is what exact characters that should be
used
to represent this operator? I really hope we can get this implemented
quickly... I worked with $_POST yesterday and I could really use that ??
operator.
I can agree that implementing ?? with isset() and not array_key_exists()
would be acceptable... but empty() is a blunt compromise and much less
used... The general problem is the notice being thrown when array indexes
doesn't exist - which results in code duplication when you deal with it
nicely. e
On Thu, Apr 14, 2011 at 10:05 AM, Hannes Landeholm wrote:
> Trying to summarize this discussion... I think we can all agree that the
> main problem is "code duplication for array access when parameters are
> possibly not existing". I think we all can also agree that @ can be both
> used properly a
On 15/04/11 12:05 AM, Hannes Landeholm wrote:
Trying to summarize this discussion... I think we can all agree that the
main problem is "code duplication for array access when parameters are
possibly not existing".
For me the problem is 'code duplication when a value might be null'
(whether an a
Trying to summarize this discussion... I think we can all agree that the
main problem is "code duplication for array access when parameters are
possibly not existing". I think we all can also agree that @ can be both
used properly and misused - and it is a blunt tool and not a nice solution
to the
Sometimes this is true, but sometimes not. For example, HTTP GET/POST interfaces
often have optional parameters. These need to be tested for, and often defaults
provided, to write solid code.
Saying you can always wrap it is like saying you can write your programs for a
Turing machine.
Also,
arrays are intent for holding values, not for represent things so use
objects for that.
the need for array_key_exists/isset to check for the presence of an index is
a smell that you need to refactor your code for a different datatype.
If you cannot change the array, you always can wrap it.
With g
I cry whenever I see code with @ in it...
I don't like @ either. The whole point of this proposal though is to
offer a safe alternative, a way to suppress only those notices which are
being accounted for by the programmer and no more, without messing
around making a custom error handler that ign
Martin Scotta
On Thu, Apr 14, 2011 at 8:58 AM, Ben Schmidt
wrote:
> 1. Suppression of notice. I agree, it is best done only for array
>>> keys. It's not hard to initialise a variable with $var=null at the
>>> beginning of a code block to avoid such a notice, and that is the
>>> appropriate way
There are two issues here.
1. Suppression of notice. I agree, it is best done only for array
keys. It's not hard to initialise a variable with $var=null at the
beginning of a code block to avoid such a notice, and that is the
appropriate way to do it for variables.
2. Offerin
>
>
> I'm aware there are cases where @ still has to be used. What I meant was
> that PHP should let you write clean code that doesn't require error
> suppression, or require you to jump through hoops to avoid errors. I look
> forward to the day when that might be possible.
>
> David
>
>
>
there wi
On 14/04/11 10:08 PM, Jordi Boggiano wrote:
On 14.04.2011 13:58, Ben Schmidt wrote:
I have many, many uses for this. E.g. patterns like this:
class Foo {
private $defaultBar;
public function foobar(Bar $bar=null) {
$bar = isset($bar) ? $bar : $this->defaultBar;
$bar->doSom
On 14.04.2011 13:58, Ben Schmidt wrote:
> I have many, many uses for this. E.g. patterns like this:
>
> class Foo {
>private $defaultBar;
>public function foobar(Bar $bar=null) {
> $bar = isset($bar) ? $bar : $this->defaultBar;
> $bar->doSomething();
>}
> }
I'm sorry but t
1. Suppression of notice. I agree, it is best done only for array
keys. It's not hard to initialise a variable with $var=null at the
beginning of a code block to avoid such a notice, and that is the
appropriate way to do it for variables.
2. Offering a shortcut for the common idiom isset($x) ? $x
inline posted
> I cry whenever I see code with @ in it...
>
>
I always cry when somebody thinks that the @ cannot be used correctly.
btw we have the scream extension and xdebug.scream also, and you could use
an error handler to "scream" the errors suppressed by @, so I don't know why
are you cryi
On 14 April 2011 11:07, Reindl Harald wrote:
>
> Am 14.04.2011 12:02, schrieb Richard Quadling:
>
>> I always declare my variables. So, I don't want to use isset() as they
>> will be an incorrect test. I use is_null(). Specifically testing the
>> value. If I've made a mistake and NOT declared the
On Thu, 14 Apr 2011 10:59:41 +0200, Eloy Bote Falcon
wrote:
What is the purpose of that generateHash function? It doesn't work in the
isset check.
Instead of using a multi-dimensional array, I use a flat array.
Anyway, you can do a simple $a = array('foo'); isset($a[$x][$y][$z])
without
Am 14.04.2011 12:02, schrieb Richard Quadling:
> I always declare my variables. So, I don't want to use isset() as they
> will be an incorrect test. I use is_null(). Specifically testing the
> value. If I've made a mistake and NOT declared the variable (or made a
> typo), I want to know. I don't
On 14 April 2011 09:59, Eloy Bote Falcon wrote:
> What is the purpose of that generateHash function? It doesn't work in the
> isset check.
>
> Anyway, you can do a simple $a = array('foo'); isset($a[$x][$y][$z]) without
> notices at all unless any of $x $y or $z are not defined, you don't need to
What is the purpose of that generateHash function? It doesn't work in the
isset check.
Anyway, you can do a simple $a = array('foo'); isset($a[$x][$y][$z]) without
notices at all unless any of $x $y or $z are not defined, you don't need to
check the indexes one by one.
2011/4/14 Ole Markus With
On Thu, 14 Apr 2011 02:24:56 +0200, Ben Schmidt
wrote:
I think these shortcuts could be really useful for array elements, but
for other variables I am really sceptical and I think they would do
more harm than good. Generally I do not really see any reason why a
variable should not be 'instanc
Bottom posted.
On 14/04/11 09:24, Ben Schmidt wrote:
>> I think these shortcuts could be really useful for array elements, but
>> for other variables I am really sceptical and I think they would do
>> more harm than good. Generally I do not really see any reason why a
>> variable should not be 'in
I think these shortcuts could be really useful for array elements, but
for other variables I am really sceptical and I think they would do
more harm than good. Generally I do not really see any reason why a
variable should not be 'instanciated' before use.
So
+1 if this shortcut is implemented to
Am 12.04.2011 13:33, schrieb Richard Quadling:
Notice: Undefined variable
Notice: Undefined index
To me, these two notices are totally different in severity, but that may
be because of how i write my code. I'd like to be able to get rid of the
"Undefined index" Notice in a nice, clean, readab
On 12 April 2011 12:33, Richard Quadling wrote:
> [1] http://pastebin.com/qLNYtfAw
Updated to http://pastebin.com/cqSEcGpN to include 0 and '' values.
The output is ...
Undefined variableisset() = false empty() = true
defined = false
Defined variable null value isset() =
Considering that the main impetus for these threads is to write code
that does not generate the notice regarding missing variables or
indices, neither isset() or empty() will provide that completely.
If a variable is declared, but assigned null, it is not set and it is
empty. But so what. The vari
On Mon, Apr 11, 2011 at 4:09 PM Chris Stockton wrote:
> My suggestion to use ?? I will say has little to do with laziness. I
> would be happy with any solution that solves my problem, I just know
> that implementing a patch for ?? would be simple enough (I could even
> do so if requested). Everyon
Em Tue, 12 Apr 2011 10:04:36 +0100, Stas Malyshev
escreveu:
It seems that there are no consensus about this feature so...
*if in doubt, leave it out.*
I don't see any serious objections to it except comments from people
that seem not really understand what this feature is about and compl
Hi!
It seems that there are no consensus about this feature so...
*if in doubt, leave it out.*
I don't see any serious objections to it except comments from people
that seem not really understand what this feature is about and complain
about "bad code" which has nothing to do with the actua
It seems that there are no consensus about this feature so...
*if in doubt, leave it out.*
Martin Scotta
On Mon, Apr 11, 2011 at 5:09 PM, Chris Stockton
wrote:
> Hello,
>
> On Mon, Apr 11, 2011 at 11:47 AM, Matthew Weier O'Phinney
> wrote:
> > On 2011-04-11, Stas Malyshev wrote:
> >> > I m
Hello,
On Mon, Apr 11, 2011 at 11:47 AM, Matthew Weier O'Phinney
wrote:
> On 2011-04-11, Stas Malyshev wrote:
>> > I might come off rather crumudgeonly here, but these last few
>> > threads I've seen going across to silence notices have a common
>> > theme - "I wanna be a lazier coder."
My sugg
On 2011-04-11, Stas Malyshev wrote:
> > I might come off rather crumudgeonly here, but these last few
> > threads I've seen going across to silence notices have a common
> > theme - "I wanna be a lazier coder."
>
> Laziness is a virtue for a coder :) At least, when it goes to avoid
> unnecessary w
Hi!
I might come off rather crumudgeonly here, but these last few threads I've
seen going across to
silence notices have a common theme - "I wanna be a lazier coder."
Laziness is a virtue for a coder :) At least, when it goes to avoid
unnecessary work - in this example, boilerplate code.
W
Le 11/04/2011 19:17, Michael Morris a écrit :
> But don't ask the engine to be rewritten to encourage bad coding practices
> which failing to properly initialize variables is a prime example of. It's
> this sort of thinking that got register_globals and magic_quotes put into
> the language no doub
I might come off rather crumudgeonly here, but these last few threads I've
seen going across to
silence notices have a common theme - "I wanna be a lazier coder."
Which is fine - set the PHP error level to not show them.
But don't ask the engine to be rewritten to encourage bad coding practices
w
On Apr 10 21:22:58, D. Dante Lorenso wrote:
> The problem with implementing "ifsetor", "filled", or "??" in userland
> is that the "not set" or "undefined" warning is fired before the
> variable is passed to the underlying function/method.
>
> Is it possible to add a modifier that turns off warn
If doing the suppression of undefined notices be better if the ? was put after
the
opening square bracket, thereby removing the ambiguity (which I think would be
more troublesome than you think)? $array[?"foo"]
I suppose a non-array-specific version would be to put it after the $.
$?variable
$
I think another problem with using @ is that it is done by the caller,
not the callee, so it doesn't allow functions like issetor() to be
implemented in userland without expecting every caller to do pass the
variable while silencing errors.
I also don't think the inconvenience is restricted to ar
@ is not convenient since it turns off error reporting for all errors. I
don't know how many times I've silenced a notice and got a blank page in my
face as a "thank you for accidentally silencing that fatal error too".
"Silent" is reserved for the purpose of the silence operator though @ so
using
Hi!
@.
Note however it does not exactly "turn off" the warning, only changes it
to not reported. It's still generated and can be picked up by handlers,
for example.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Ru
@.
On Apr 10, 2011, at 9:22 PM, D. Dante Lorenso wrote:
> The problem with implementing "ifsetor", "filled", or "??" in userland is
> that the "not set" or "undefined" warning is fired before the variable is
> passed to the underlying function/method.
>
> Is it possible to add a modifier that
The problem with implementing "ifsetor", "filled", or "??" in userland
is that the "not set" or "undefined" warning is fired before the
variable is passed to the underlying function/method.
Is it possible to add a modifier that turns off warnings for undefined
variables whenever that specific
On Sun, Apr 10, 2011 at 10:04 AM, Rune Kaagaard wrote:
> Hey again
>
> Updated here as always https://gist.github.com/909711. I've tried to
> write down the goal of this new feature. Which patterns do we want to
> make easier to write?
>
> Do you agree with the goals I've set?
>
> +1 From me of c
On Sun, 10 Apr 2011 16:04:06 +0200, Rune Kaagaard
wrote:
Hey again
Updated here as always https://gist.github.com/909711. I've tried to
write down the goal of this new feature. Which patterns do we want to
make easier to write?
Do you agree with the goals I've set?
I think these shortcut
Hey again
Updated here as always https://gist.github.com/909711. I've tried to
write down the goal of this new feature. Which patterns do we want to
make easier to write?
Do you agree with the goals I've set?
+1 From me of course :)
Also added a proposal that would make userland implementations
Sanford Whiteman wrote:
> Same here.
>
> Here's my take:
>
> [1] I don't like ?? / ? because it is disjunctive with === / ==.. The
> extra equals sign strengthens equality comparison, while the extra
> question mark essentially _weakens_ the ternary operator (making it
> more forgiving). (
On 4/7/11 5:35 PM, Etienne Kneuss wrote:
On Apr 07 18:03:48, Rasmus Lerdorf wrote:
On 4/7/11 5:59 PM, Matthew Weier O'Phinney wrote:
It may change the semantics as they stand, but I'd argue that the
_expectation_ from the shorthand ternary is to shorten code that
currently uses isset(). As it i
Hi guys
Below is a discussion about some of the issues being raised. Again a
nicely formatted version of the whole thing is here:
https://gist.github.com/909711.
## Discussion ##
### About changing the beviour of the ternary shortcut ###
@Jordi, others
Some suggest adding an implicit `isset` a
> First post here; been watching for a while though.
Same here.
Here's my take:
[1] I don't like ?? / ? because it is disjunctive with === / ==.. The
extra equals sign strengthens equality comparison, while the extra
question mark essentially _weakens_ the ternary operator (making it
mo
On 9/04/11 12:45 AM, Martin Scotta wrote:
I just feels that !empty($arr['key']) or isset($arr['key']) do not express
the real meaning, instead I would choose to write array_key_exists('key',
$arr). It may be slower but it clearly express what I meant.
I don't like this. array_key_exists will re
Hello all,
First post here; been watching for a while though.
IMHO:
1) Implicit isset() checks in ?: would be bad. This would not
"silently improve not-so-well written code"; In fact it would make
not-so-well written code more difficult to debug. I can't count the
number of times I've run across c
Operators should have very specific purpose and function... a ternary if
statement should just be another way to express a normal if statement.
Making the ? operator suppress the not defined error would be a poor
compromise, making PHP inconsistent. Then I'd rather have access of
non-defined array
I just feels that !empty($arr['key']) or isset($arr['key']) do not express
the real meaning, instead I would choose to write array_key_exists('key',
$arr). It may be slower but it clearly express what I meant.
Regarding the operators, I believe they will do more harm than good.
To check if a varia
I think "?!" wouldn't work as an operator as it would conflict with ternary
comparision + not operator. Also I don't see the point of adding an operator
for "empty" as the function/construct itself is pretty confusing and
non-useful as you have to memorize all the things that happen to be
considere
On 08.04.2011 15:19, Rune Kaagaard wrote:
> New syntax:
> // a)
> $a = get_stuff('foo') ?? 42;
>
> // b)
> $a = get_stuff('foo') ?! 42;
This is wrong. The "new syntax" is already available since 5.3.0 and is
$a = get_stuff('foo') ?: 42;
Now I agree with you, it sounds great and
Dear Internals
I'm very happy that this is getting some attention again. Please allow
me to give my 2 cents too. The text below can also be seen nicely
formatted at https://gist.github.com/909711.
## Intro ##
Isset and IsNotEmpty operators have for sure been a hot topic for several years
now and
Hi. I like Adam's suggestion _a lot_ however I'd also find a third
case very useful.
In addition to:
*
// standard
$value = isset($a[$key]) ? $a[$key] : 'Not set';
// new ?? double ternary that performs isset check and omits second
expression
$value = $a[$key] ?? : 'Not set';
// new ?? d
> -Original Message-
> From: Adam Richardson [mailto:simples...@gmail.com]
> Sent: 08 April 2011 08:02
>
> Indeed.
>
> The '?' character already is special, so using '??' seems like a
> safe,
> practical approach. However, I'd prefer maintaining the form of the
> standard
> ternary oper
Hi, just to drop an opinion on something I felt natural when reading this:
how about a word instead?:
$value = 'Not set' unless $a['key'];
I think it would be way more readable.
Regards,
David
On Fri, Apr 8, 2011 at 2:02 AM, Adam Richardson wrote:
> >
> >
> >> We need to be careful about cha
>
>
>> We need to be careful about changing the beahviour of existing
> operators.
>
Indeed.
The '?' character already is special, so using '??' seems like a safe,
practical approach. However, I'd prefer maintaining the form of the standard
ternary operator with the colon ($value = $var['bar'] ?
On 04/07/2011 07:02 PM, Stas Malyshev wrote:
Hi!
$value = isset($a[$key]) ? $a[$key] : 'Not set';
which is exactly the situation I had before it was introduced.
Not sure why you would have that expectation. The long ternary doesn't
do that, and there is nothing about the short ternary that c
On 8/04/11 4:41 AM, Rasmus Lerdorf wrote:
On 4/7/11 2:30 PM, Rafael Dohms wrote:
On Thu, Mar 31, 2011 at 7:46 PM, Ben Schmidt
wrote:
On 1/04/11 3:29 AM, David Coallier wrote:
Hey there,
I've been working on a little patch that will allow variables ($1) in
a short-ternary operation to go thr
Hi!
$value = isset($a[$key]) ? $a[$key] : 'Not set';
which is exactly the situation I had before it was introduced.
Not sure why you would have that expectation. The long ternary doesn't
do that, and there is nothing about the short ternary that changes that.
It is true, however I thi
On Apr 07 18:03:48, Rasmus Lerdorf wrote:
> On 4/7/11 5:59 PM, Matthew Weier O'Phinney wrote:
> > It may change the semantics as they stand, but I'd argue that the
> > _expectation_ from the shorthand ternary is to shorten code that
> > currently uses isset(). As it is, I have almost no use for it
Hello,
On Thu, Apr 7, 2011 at 3:03 PM, Rasmus Lerdorf wrote:
> On 4/7/11 5:59 PM, Matthew Weier O'Phinney wrote:
>>
>> It may change the semantics as they stand, but I'd argue that the
>> _expectation_ from the shorthand ternary is to shorten code that
>> currently uses isset(). As it is, I have
On 4/7/11 5:59 PM, Matthew Weier O'Phinney wrote:
It may change the semantics as they stand, but I'd argue that the
_expectation_ from the shorthand ternary is to shorten code that
currently uses isset(). As it is, I have almost no use for it at this
point, as I end up needing to do:
$value
On 2011-04-07, Rasmus Lerdorf wrote:
> On 4/7/11 2:30 PM, Rafael Dohms wrote:
> > On Thu, Mar 31, 2011 at 7:46 PM, Ben Schmidt
> > wrote:
> > > On 1/04/11 3:29 AM, David Coallier wrote:
> > > > I've been working on a little patch that will allow variables ($1) in
> > > > a short-ternary operatio
On 4/7/11 2:30 PM, Rafael Dohms wrote:
On Thu, Mar 31, 2011 at 7:46 PM, Ben Schmidt
wrote:
On 1/04/11 3:29 AM, David Coallier wrote:
Hey there,
I've been working on a little patch that will allow variables ($1) in
a short-ternary operation to go through an implicit isset
(zend_do_isset_or_i
On Thu, Mar 31, 2011 at 7:46 PM, Ben Schmidt
wrote:
> On 1/04/11 3:29 AM, David Coallier wrote:
>>
>> Hey there,
>>
>> I've been working on a little patch that will allow variables ($1) in
>> a short-ternary operation to go through an implicit isset
>> (zend_do_isset_or_isempty) check so that the
On 1/04/11 3:29 AM, David Coallier wrote:
Hey there,
I've been working on a little patch that will allow variables ($1) in
a short-ternary operation to go through an implicit isset
(zend_do_isset_or_isempty) check so that the average use-case for the
short-ternary operator doesn't yield in a not
Hey there,
I've been working on a little patch that will allow variables ($1) in
a short-ternary operation to go through an implicit isset
(zend_do_isset_or_isempty) check so that the average use-case for the
short-ternary operator doesn't yield in a notice whenever the first
variable of the expre
93 matches
Mail list logo
