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
hi Marius,
Please fill a SVN account request at:
http://www.php.net/svn-php.php
Thanks for your contribs so far!
Cheers,
On Thu, Apr 14, 2011 at 12:25 PM, marius adrian popa wrote:
> Hello ,
> I need svn access rights : mostly on the firebird driver area, on wiki
> I'm : mariuz
> I have serve
On Thu, Apr 14, 2011 at 12:25 PM, marius adrian popa wrote:
> Hello ,
> I need svn access rights : mostly on the firebird driver area, on wiki
> I'm : mariuz
> I have serveral patches in the queue and (related to null parameters
> http://bugs.php.net/bug.php?id=54426, new api reported on mailing l
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
Hello ,
I need svn access rights : mostly on the firebird driver area, on wiki
I'm : mariuz
I have serveral patches in the queue and (related to null parameters
http://bugs.php.net/bug.php?id=54426, new api reported on mailing list
...)
One example i work on is
http://bugs.php.net/48447
Tested wi
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
27 matches
Mail list logo
