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
On Sat, Apr 23, 2011 at 1:21 PM, Hannes Landeholm landeh...@gmail.comwrote:
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
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
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
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 mail_ben_schm...@yahoo.com.au
wrote:
On 21/04/11 9:56 AM, Arpad
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 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
from the
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.
On Thu, Apr 14, 2011 at 3:05 PM, Hannes Landeholm landeh...@gmail.com 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
On Thu, Apr 21, 2011 at 12:56 AM, Arpad Ray array...@gmail.com 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
On 21/04/11 08:56, Arpad Ray wrote:
On Thu, Apr 14, 2011 at 3:05 PM, Hannes Landeholm landeh...@gmail.com 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
On Sat, 16 Apr 2011 03:42:11 +0200, Adam Richardson simples...@gmail.com
wrote:
On Fri, Apr 15, 2011 at 8:46 PM, Ben Schmidt
mail_ben_schm...@yahoo.com.auwrote:
There was also my suggestion of a checked ternary operator [see my
previous email in this thread.] Backwards compatible,
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']),
$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
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'd much
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 an
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
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 is
On Fri, Apr 15, 2011 at 8:46 PM, Ben Schmidt
mail_ben_schm...@yahoo.com.auwrote:
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
On Thu, 14 Apr 2011 02:24:56 +0200, Ben Schmidt
mail_ben_schm...@yahoo.com.au 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
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 14 April 2011 09:59, Eloy Bote Falcon eloyb...@gmail.com 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
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 Thu, 14 Apr 2011 10:59:41 +0200, Eloy Bote Falcon eloyb...@gmail.com
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');
On 14 April 2011 11:07, Reindl Harald h.rei...@thelounge.net 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
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 crying.
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) ?
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 this is not
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;
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 will always
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.
Martin Scotta
On Thu, Apr 14, 2011 at 8:58 AM, Ben Schmidt
mail_ben_schm...@yahoo.com.auwrote:
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
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
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
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.
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
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
On Thu, Apr 14, 2011 at 10:05 AM, Hannes Landeholm landeh...@gmail.comwrote:
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
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.
On Thu, 14 Apr 2011 16:05:45 +0200, Hannes Landeholm landeh...@gmail.com
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
On Thu, 14 Apr 2011 15:25:45 +0200, Martin Scotta martinsco...@gmail.com
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
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 =
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
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
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
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 actual
Em Tue, 12 Apr 2011 10:04:36 +0100, Stas Malyshev smalys...@sugarcrm.com
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
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). Everyone
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
On 12 April 2011 12:33, Richard Quadling rquadl...@gmail.com 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
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,
@ 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
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
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
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 warnings for
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
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 doubt.
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.
On 2011-04-11, Stas Malyshev smalys...@sugarcrm.com 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
Hello,
On Mon, Apr 11, 2011 at 11:47 AM, Matthew Weier O'Phinney
weierophin...@php.net wrote:
On 2011-04-11, Stas Malyshev smalys...@sugarcrm.com 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
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
chrisstockto...@gmail.comwrote:
Hello,
On Mon, Apr 11, 2011 at 11:47 AM, Matthew Weier O'Phinney
weierophin...@php.net wrote:
On
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
On Sun, 10 Apr 2011 16:04:06 +0200, Rune Kaagaard rumi...@gmail.com
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
On Sun, Apr 10, 2011 at 10:04 AM, Rune Kaagaard rumi...@gmail.com 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
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 method is
@.
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 turns off
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
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`
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
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). (Sure, a
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'] ?? :
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 simples...@gmail.comwrote:
We need to be
-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 operator with
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 ??
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
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 all,
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
considered
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
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
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
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
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
On Thu, Mar 31, 2011 at 7:46 PM, Ben Schmidt
mail_ben_schm...@yahoo.com.au 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)
On 4/7/11 2:30 PM, Rafael Dohms wrote:
On Thu, Mar 31, 2011 at 7:46 PM, Ben Schmidt
mail_ben_schm...@yahoo.com.au 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
On 2011-04-07, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 4/7/11 2:30 PM, Rafael Dohms wrote:
On Thu, Mar 31, 2011 at 7:46 PM, Ben Schmidt
mail_ben_schm...@yahoo.com.au wrote:
On 1/04/11 3:29 AM, David Coallier wrote:
I've been working on a little patch that will allow variables ($1)
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:
Hello,
On Thu, Apr 7, 2011 at 3:03 PM, Rasmus Lerdorf ras...@lerdorf.com 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
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 at
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
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
mail_ben_schm...@yahoo.com.au 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
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
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
92 matches
Mail list logo
