Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

[Ben Schmidt]

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 operator
for the default, and a separate error-suppression mechanism, people
could use the suppression mechanism with the existing boolean ternary
operator if they want to (I would find that useful, as I often write
things such as isset($a[$k])&&$a[$k]?"yes":"no" for that kind of thing),
and use the !==null operator without error suppression (I would find
that useful, too, to avoid typos).

In summary, with two separate, simpler mechanisms, we could tackle these
paradigms (I have used @[...] for undefined index error-suppression and
$: for !==null default):

1. $v!==null ? $v : "default"
   $v $: "default"
   with notice

2. $a[$k]!==null ? $a[$k] : "default"
   $a[$k] $: "default"
   with notice

3. isset($a[$k]) ? $a[$k] : "default"
   $a@[$k] $: "default"
   without notice

4. isset($a[$k]) ? $a[$k] : null
   $a@[$k]
   without notice

5. isset($a[$k])&&!!$a[$k]
   !!$a@[$k]
   without notice

6. isset($a[$k])&&$a[$k] ? "yes" : "no"
   $a@[$k] ? "yes" : "no"
   without notice

With !==null assignment (I've used $:=) we could also have:

7. if (!isset($a[$k])) $a[$k] = "default";
   $a[$k] $:= "default";
   without notice (the LHS of an assignment never generates one)

To avoid encouraging poor coding, we would deliberately not have:

8. isset($v) ? $v : "default"
   $@v $: "default"
   without notice

But it is a cinch to add it if enough people want it, and doing so
wouldn't affect anyone who didn't want to use it--no backward
compatibility problems on the horizon. I think that's the clincher. If
we just add an isset() operator (that suppresses errors, and gives a
default), we only get paradigms 3, 4, 5 and maybe 7, but worse, if we
want to add any of the others later, we need to design more complicated
new operators, or break backward compatibility, not just extend what we
have.

I personally use 1, 3, 5 and 6 quite often, and 2 and 7 occasionally, so
I see great value in being able to do them all, not just the restricted
set.

What numbers are others interested in being able to solve?

What do others think about the future-proofing issue?

Ben.



On 15/04/11 1:01 AM, Hannes Landeholm wrote:

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. empty() tries to be a
generic solution but there will always be people that has some other special
definition of "emptiness" like "array that contains a single null value" and 
they
need to write the code that defines that particular comparison anyway.

You can't have a solution that makes everything easier for everyone so let's 
solve
one thing at a time and start with the most generic problem specifically and not
all minor problems that happens to partially intersect that one.

~Hannes


On 14 April 2011 16:26, Ben Schmidt mailto:mail_ben_schm...@yahoo.com.au>> wrote:

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 array, variable or something else, and regardless of whether
it was set to null, or not defined at all).


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
previously stated problem.


Yes.


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.


Yes.


Some suggested ?? as an array access operator that suppresses the 
notice and
has 3 variants: A: nothing specified - uses null as default, B: has 
default
specified, C: returns X if index exists or Y if index doesn't exist. 
This
effectively solves the code duplication problem and is a shortcut for 
saying
"the array index may or may not exist".


This only works if the test is made an isset() kind of test. If it
remains a boolean cast, it doesn't help much. (Or at least it doesn't
help me much.)

I also think it's a bit too blunt. In all but the simplest expressions
in the condition, desired notices could be silenced. I like the idea of
being able to specify exactly which array lookups should be silenced.

It also doesn't h

Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

[Hannes Landeholm]

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 = \intval(@$_POST["field"]);

(or a boolean:)

$value = (@$_POST["field"] == "set");

I'd prefer this syntax though:

$value = \intval($_POST["field"]??);


..simply because it's a more precise expression and no notice is generated
and have to be ignored when running the custom error handler - so it should
be faster too.

~Hannes

On 14 April 2011 18:08, Ole Markus With  wrote:

> 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.
>>
>>
> When it comes to $_POST you probably want to use filter_input instead.
>
> Cheers,
> Ole Markus With
>

Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

[Ole Markus With]

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.



There is quite a difference in performance between using an array  
representation of data structures such as graphs, matrices, etc and using  
an OO representation. Also with the inclusion of closures it is possible  
to write very elegant code using arrays and array functions such as  
array_walk, array_map etc. If the multi-dimensional array is sparse, you  
cannot really avoid a lot of isset calls.


Also, if you want to output everything as json in the end, working on  
arrays is very natural.


--
Ole Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

[Ole Markus With]

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.



When it comes to $_POST you probably want to use filter_input instead.

Cheers,
Ole Markus With

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

[Hannes Landeholm]

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. empty() tries to be a generic solution but there will always be
people that has some other special definition of "emptiness" like "array
that contains a single null value" and they need to write the code that
defines that particular comparison anyway.

You can't have a solution that makes everything easier for everyone so let's
solve one thing at a time and start with the most generic problem
specifically and not all minor problems that happens to partially intersect
that one.

~Hannes


On 14 April 2011 16:26, Ben Schmidt  wrote:

> 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 array, variable or something else, and regardless of whether
> it was set to null, or not defined at all).
>
>
>  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
>> previously stated problem.
>>
>
> Yes.
>
>
>  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.
>>
>
> Yes.
>
>
>  Some suggested ?? as an array access operator that suppresses the notice
>> and
>> has 3 variants: A: nothing specified - uses null as default, B: has
>> default
>> specified, C: returns X if index exists or Y if index doesn't exist. This
>> effectively solves the code duplication problem and is a shortcut for
>> saying
>> "the array index may or may not exist".
>>
>
> This only works if the test is made an isset() kind of test. If it
> remains a boolean cast, it doesn't help much. (Or at least it doesn't
> help me much.)
>
> I also think it's a bit too blunt. In all but the simplest expressions
> in the condition, desired notices could be silenced. I like the idea of
> being able to specify exactly which array lookups should be silenced.
>
> It also doesn't help the people who want an isset() style test, but
> without the notice suppression, and I think there are a few people in
> that category.
>
>
>  One person said that the relation between ? and ?? and == and === would
>> make
>> the operator non-intuitive. Other people disagreed and claimed the
>> opposite.
>>
>> 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 still don't think we've reached agreement on exactly what we need.
> Your summary seems to me to be of some of the earliest and least
> developed ideas. I think the discussion has moved in a number of
> interesting directions since then and we should draw on that later work.
>
> Ben.
>
>
>
>

Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

[Adam Richardson]

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 and misused - and it is a blunt tool and not a nice solution
> to the previously stated problem.
>
> 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 an array access operator that suppresses the notice
> and
> has 3 variants: A: nothing specified - uses null as default, B: has default
> specified, C: returns X if index exists or Y if index doesn't exist. This
> effectively solves the code duplication problem and is a shortcut for
> saying
> "the array index may or may not exist".
>
> One person said that the relation between ? and ?? and == and === would
> make
> the operator non-intuitive. Other people disagreed and claimed the
> opposite.
>
> 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.
>
> ~Hannes
>

There was also my suggestion of a "checked ternary" operator [see my
previous email in this thread.] Backwards compatible, practical, and simple.

Adam

-- 
Nephtali:  A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com

Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

[Ben Schmidt]

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 array, variable or something else, and regardless of whether
it was set to null, or not defined at all).


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
previously stated problem.


Yes.


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.


Yes.


Some suggested ?? as an array access operator that suppresses the notice and
has 3 variants: A: nothing specified - uses null as default, B: has default
specified, C: returns X if index exists or Y if index doesn't exist. This
effectively solves the code duplication problem and is a shortcut for saying
"the array index may or may not exist".


This only works if the test is made an isset() kind of test. If it
remains a boolean cast, it doesn't help much. (Or at least it doesn't
help me much.)

I also think it's a bit too blunt. In all but the simplest expressions
in the condition, desired notices could be silenced. I like the idea of
being able to specify exactly which array lookups should be silenced.

It also doesn't help the people who want an isset() style test, but
without the notice suppression, and I think there are a few people in
that category.


One person said that the relation between ? and ?? and == and === would make
the operator non-intuitive. Other people disagreed and claimed the opposite.

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 still don't think we've reached agreement on exactly what we need.
Your summary seems to me to be of some of the earliest and least
developed ideas. I think the discussion has moved in a number of
interesting directions since then and we should draw on that later work.

Ben.




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

[Hannes Landeholm]

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 previously stated problem.

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 an array access operator that suppresses the notice and
has 3 variants: A: nothing specified - uses null as default, B: has default
specified, C: returns X if index exists or Y if index doesn't exist. This
effectively solves the code duplication problem and is a shortcut for saying
"the array index may or may not exist".

One person said that the relation between ? and ?? and == and === would make
the operator non-intuitive. Other people disagreed and claimed the opposite.

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.

~Hannes

Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

[Ben Schmidt]

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, not everyone is writing highly abstracted object-oriented code in PHP.

Ben.



On 14/04/11 11:25 PM, 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.

If you cannot change the array, you always can wrap it.

With good data abstractions the usage of array_key_exists/isset/empty is barely
reduced to the minimum.

  Martin Scotta


On Thu, Apr 14, 2011 at 10:12 AM, Ben Schmidt mailto:mail_ben_schm...@yahoo.com.au>> wrote:

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. Offering a shortcut for the common idiom isset($x) ? 
$x
: $y in
line with the DRY design principle. A notice would never
be emitted
here in any case. The problem is that this idiom is 
still
in wide use
despite the shortcut ternary operator already provided,
because an
isset() check is different to a boolean cast.

Some thoughts:

- The actual intent of 2. is probably $x!==null ? $x : 
$y
i.e. it's
  not about suppressing notices at all, but about 
offering
a default
  value, and the idiom quite probably only uses isset()
because it
  predated null in the language.

- If we view 2. in this way, the two problems are
independent, and it
  seems to me it would be best to solve them
independently, rather
  than with a single operator.

So, I suggest:

1. An array lookup mechanism that suppresses the notice
for undefined
keys. It would work the same as regular array index
lookups except
that the notice for undefined keys (and only for 
undefined
keys)
would not be generated (it would not just be hidden, but
would never
be even generated).

http://news.php.net/php.internals/51877

array_key_exists($key, $array) for arrays
array_key_exists($varname, get_defined_vars()) for locally scoped 
variables.


Apart from being long and ugly, surely that is horribly inefficient.

No need to use @.


True. And I don't think anybody is. We all know @ is dangerous and nasty
and don't use it. We're not seeking an alternative to @, we're seeking
an alternative to repeating ourselves by using
isset()/array_key_exists()/is_null() as well as the value being tested.

But we don't want to do this in a blanket way similar to @ where a whole
bunch of notices are suppressed. We want to specify precisely where
missing values are allowable by indicating exactly which array index
lookups may silently fail (and evaluate to null).

Basically we don't want to make again the mistake that @ was.


Are they attempting to determine the existence of a variable/index
entry or are they attempting to determine if the variable/element is
null.


For me, existence and nullness are basically the same, and I think this
is the common case. The whole point of being able to set something to
null is to have a 'value' to represent 'unsetness'. This is why I think
solving the conditional problem should use a !==null test. That gives
the flexibility to use/pass null to represent 'unsetness' but doesn't
pick up zero, false, etc. like a boolean cast does. Using
array_key_exists() would remove that flexibility and be less useful.

As far as silencing notices goes, the rationale is that basically we
want to flag that 'null is OK, even if it's a fallback'. I.e. we don't
care whether a value is null because it was set to null, or because null
is a fallback because the variable w

Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

[Martin Scotta]

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 good data abstractions the usage of array_key_exists/isset/empty is
barely reduced to the minimum.

 Martin Scotta


On Thu, Apr 14, 2011 at 10:12 AM, Ben Schmidt  wrote:

> 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. Offering a shortcut for the common idiom isset($x) ? $x : $y in
>line with the DRY design principle. A notice would never be emitted
>here in any case. The problem is that this idiom is still in wide
> use
>despite the shortcut ternary operator already provided, because an
>isset() check is different to a boolean cast.
>
> Some thoughts:
>
>- The actual intent of 2. is probably $x!==null ? $x : $y i.e. it's
>  not about suppressing notices at all, but about offering a default
>  value, and the idiom quite probably only uses isset() because it
>  predated null in the language.
>
>- If we view 2. in this way, the two problems are independent, and
> it
>  seems to me it would be best to solve them independently, rather
>  than with a single operator.
>
> So, I suggest:
>
>1. An array lookup mechanism that suppresses the notice for
> undefined
>keys. It would work the same as regular array index lookups except
>that the notice for undefined keys (and only for undefined keys)
>would not be generated (it would not just be hidden, but would never
>be even generated).
>
>  http://news.php.net/php.internals/51877
>>
>> array_key_exists($key, $array) for arrays
>> array_key_exists($varname, get_defined_vars()) for locally scoped
>> variables.
>>
>
> Apart from being long and ugly, surely that is horribly inefficient.
>
>  No need to use @.
>>
>
> True. And I don't think anybody is. We all know @ is dangerous and nasty
> and don't use it. We're not seeking an alternative to @, we're seeking
> an alternative to repeating ourselves by using
> isset()/array_key_exists()/is_null() as well as the value being tested.
>
> But we don't want to do this in a blanket way similar to @ where a whole
> bunch of notices are suppressed. We want to specify precisely where
> missing values are allowable by indicating exactly which array index
> lookups may silently fail (and evaluate to null).
>
> Basically we don't want to make again the mistake that @ was.
>
>
>  Are they attempting to determine the existence of a variable/index
>> entry or are they attempting to determine if the variable/element is
>> null.
>>
>
> For me, existence and nullness are basically the same, and I think this
> is the common case. The whole point of being able to set something to
> null is to have a 'value' to represent 'unsetness'. This is why I think
> solving the conditional problem should use a !==null test. That gives
> the flexibility to use/pass null to represent 'unsetness' but doesn't
> pick up zero, false, etc. like a boolean cast does. Using
> array_key_exists() would remove that flexibility and be less useful.
>
> As far as silencing notices goes, the rationale is that basically we
> want to flag that 'null is OK, even if it's a fallback'. I.e. we don't
> care whether a value is null because it was set to null, or because null
> is a fallback because the variable was never defined. Either way, null
> is OK, so don't tell me about it.
>
> The conditional side lets us handle nulls nicely by providing our own
> defaults/fallbacks if it appears. The notice-suppression side lets us
> say that null is OK, even if that null itself is a fallback for
> 'undefined'. Quite often they will be used in combination, but they are
> independent.
>
>
>  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 want to hide it with isset()/empty().
>>
>
> That's exactly why I think the conditional should use a !==null test,
> not an isset() test.
>
> Ben.
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

[Ben Schmidt]

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 ignores one type of error,
which is the current way to do it 'safely'.


What we're wanting are existential assignment and ternary operators.
Simply put, a painless way to set or use a default value based on the
existence of a variable without needing a bunch of extra code to avoid
notices/errors. Sorry Ben, but I think extending the @ operator to
prevent errors from being generated in the first place is a terrible
idea. I would prefer to see @ removed from PHP if possible.


I never meant to extend @, I meant simply to reuse that symbol--i.e. the
@ character--as part of the syntax of a new safer feature, since it
performed a similar function. The actual @ operator is not changed in
any way. Rather, a new @[...] array indexing mechanism is added which
suppresses the Undefined Index notice, and only that notice, by not
generating it.


I would also want this to work with objects and scalars. It would be
particularly useful within view scripts where the values are passed in
via extract, or as object properties, and you can't instantiate them
first because that would clear them.


I guess that's a vaguely valid use case, though I still somewhat think
it is the responsibility of the caller of the view script to ensure all
variables are instantiated (to null if appropriate). I guess an
unambiguous syntax for this could be $@variable.

I guess object properties are another case. I wonder how common. I guess
$object@->property would be the way to deal with that.

I still lean towards just offering it for arrays, though. That seems to be
the area of greatest need by a significant margin.

Ben.




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

[Martin Scotta]

 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 to do it for variables.
>>>
>>> 2. Offering a shortcut for the common idiom isset($x) ? $x : $y in
>>> line with the DRY design principle. A notice would never be emitted
>>> here in any case. The problem is that this idiom is still in wide use
>>> despite the shortcut ternary operator already provided, because an
>>> isset() check is different to a boolean cast.
>>>
>>> Some thoughts:
>>>
>>> - The actual intent of 2. is probably $x!==null ? $x : $y i.e. it's
>>> not about suppressing notices at all, but about offering a default
>>> value, and the idiom quite probably only uses isset() because it
>>> predated null in the language.
>>>
>>>  I have never felt the need for a shortcut in these cases. It would be
>> interesting to see some code where this would be practical.
>>
>
> 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();
>   }
> }
>

Bad example... you could get a Bar object or a null value, so I would
write...

class Foo {
private $defaultBar; /* initialized somewhere */
public function foobar(Bar $bar=null) {
if (null === $bar) {
$bar = $this->defaultBar;
}
$bar->doSomething();
}
}



>
> The default value of null indicates that the argument is able to be
> omitted, and the type hinting mechanism understands that. Yet it's
> awkward to actually test whether it's been omitted or not without
> writing the argument multiple times. It'd be great to be able to write
> the first line succinctly, e.g.
>
> $bar $:= $this->defaultBar;
>
> That's just one case. There are many more.
>
> As I said above, though, I probably should have written $bar!==null
> rather than isset($bar), because I actually would want the warning if
> $bar was not defined (i.e. I had mistyped it).
>
>
>  - If we view 2. in this way, the two problems are independent, and it
>>> seems to me it would be best to solve them independently, rather
>>> than with a single operator.
>>>
>>> So, I suggest:
>>>
>>> 1. An array lookup mechanism that suppresses the notice for undefined
>>> keys. It would work the same as regular array index lookups except
>>> that the notice for undefined keys (and only for undefined keys)
>>> would not be generated (it would not just be hidden, but would never
>>> be even generated).
>>>
>>
>> This is what I feel PHP is missing. Particularly when it comes to
>> multi-dimensional arrays. Because this feature is missing I tend to do
>> something like
>>
>> function generateHash($x, $y, $z)
>> {
>> return "$x::$y::$z";
>> }
>>
>> if (isset($a[generateHash($x, $y, $z)]) {
>> ...
>> }
>>
>> instead of
>>
>> if (isset($a[$x]) && isset($a[$x][$y]) && isset($a[$x][$y][$z])) {
>> ...
>> }
>>
>
> I don't really understand your example, or how an error-suppressing
> array index lookup helps it, but I do think the feature is useful.
>
> I actually think there is enough support for both these things, and
> implementing them independently allows those who want to use one but not
> the other to do so.
>
>
>  Arguing about syntax is then a second step. However, my views on this
>>> are:
>>>
>>
>> I think it best to avoid discussing the actual syntax before agreeing on
>> what we
>> really need.
>>
>
> I agree. In fact I sent the previous mail by mistake; I had intended to
> archive my thoughts on syntax and send the mail without them, but I
> bumped send.
>
> Ben.
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

[Ben Schmidt]

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. Offering a shortcut for the common idiom isset($x) ? $x : $y in
line with the DRY design principle. A notice would never be emitted
here in any case. The problem is that this idiom is still in wide use
despite the shortcut ternary operator already provided, because an
isset() check is different to a boolean cast.

Some thoughts:

- The actual intent of 2. is probably $x!==null ? $x : $y i.e. it's
  not about suppressing notices at all, but about offering a default
  value, and the idiom quite probably only uses isset() because it
  predated null in the language.

- If we view 2. in this way, the two problems are independent, and it
  seems to me it would be best to solve them independently, rather
  than with a single operator.

So, I suggest:

1. An array lookup mechanism that suppresses the notice for undefined
keys. It would work the same as regular array index lookups except
that the notice for undefined keys (and only for undefined keys)
would not be generated (it would not just be hidden, but would never
be even generated).


http://news.php.net/php.internals/51877

array_key_exists($key, $array) for arrays
array_key_exists($varname, get_defined_vars()) for locally scoped variables.


Apart from being long and ugly, surely that is horribly inefficient.


No need to use @.


True. And I don't think anybody is. We all know @ is dangerous and nasty
and don't use it. We're not seeking an alternative to @, we're seeking
an alternative to repeating ourselves by using
isset()/array_key_exists()/is_null() as well as the value being tested.

But we don't want to do this in a blanket way similar to @ where a whole
bunch of notices are suppressed. We want to specify precisely where
missing values are allowable by indicating exactly which array index
lookups may silently fail (and evaluate to null).

Basically we don't want to make again the mistake that @ was.


Are they attempting to determine the existence of a variable/index
entry or are they attempting to determine if the variable/element is
null.


For me, existence and nullness are basically the same, and I think this
is the common case. The whole point of being able to set something to
null is to have a 'value' to represent 'unsetness'. This is why I think
solving the conditional problem should use a !==null test. That gives
the flexibility to use/pass null to represent 'unsetness' but doesn't
pick up zero, false, etc. like a boolean cast does. Using
array_key_exists() would remove that flexibility and be less useful.

As far as silencing notices goes, the rationale is that basically we
want to flag that 'null is OK, even if it's a fallback'. I.e. we don't
care whether a value is null because it was set to null, or because null
is a fallback because the variable was never defined. Either way, null
is OK, so don't tell me about it.

The conditional side lets us handle nulls nicely by providing our own
defaults/fallbacks if it appears. The notice-suppression side lets us
say that null is OK, even if that null itself is a fallback for
'undefined'. Quite often they will be used in combination, but they are
independent.


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 want to hide it with isset()/empty().


That's exactly why I think the conditional should use a !==null test,
not an isset() test.

Ben.




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

[Ferenc Kovacs]

>
>
> 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 be situations when an operation cannot be completed and it
has to be reported somehow.
currently a function can report the error multiple ways:
- it can return false like mysql_query, and you can fetch the error with a
different method.
- it can return NULL, like json_decode (be aware that the NULL return can
also mean success :/), and you can fetch the error with a different method.
- it can return false and trigger an error/warning/notice like iconv.
- it can throw an exception, like for example Spl and the Reflection stuff
does.
- it can do some of the above depending on some configuration option, this
is what PDO::ERRMODE_* does for example.

and what I forget to mention. :)

and it sucks that currently you cannot do some things without making errors
which are expensive, wether you collect the errors or not. :/

so I think that some reboot/refactor about the error/exception handling
would be a really good thing, of course we can do such changes only in major
or maybe with minor version bump.

another thing would be to make the error/exception handlers to be truly
stackable (so there would be possible to have more than one active handler,
be them distinct or overlapping)
and have the ability to set the class/interface when you
set_exception_handler, just like you set it for catch statements.

ps: that post went longer and more off-topic than I expected, maybe an it
would be better as an RFC...

Tyrael

Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

[Ben Schmidt]

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->doSomething();
}
}


I'm sorry but this is not a valid use case, isset() is totally
unnecessary here. You can use

   $bar = $bar ?: $this->defaultBar;

Of course it still repeats $bar, but it's not that verbose, and will
work exactly the same as what you do. I'd argue it's even better than
what you do because, if it weren't for that Bar type hint, if someone
passes false or "blah" to your function, isset() will return true, and
you'll try to call doSomething on false/"blah", which is a cute fatal error.


Actually, you'll get a cute fatal error when the function is called
because of the type hint in that case.

Anyway, yeah, sure, perhaps a bad example in its detail. I didn't spend
hours composing it. Just use a little imagination, though, and imagine
that it wasn't a type hinted object coming in, but some other value like
an integer. Then a boolean test would not work (would be false for zero
and erroneously use the default value). You then need the isset test. I
personally prefer to always use an isset/key_exists/is_null test when
I'm testing for something's 'existence' and not its 'truth'. I think
that makes the code more readable.

Ben.




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

[Jordi Boggiano]

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 a valid use case, isset() is totally
unnecessary here. You can use

  $bar = $bar ?: $this->defaultBar;

Of course it still repeats $bar, but it's not that verbose, and will
work exactly the same as what you do. I'd argue it's even better than
what you do because, if it weren't for that Bar type hint, if someone
passes false or "blah" to your function, isset() will return true, and
you'll try to call doSomething on false/"blah", which is a cute fatal error.

Cheers

-- 
Jordi Boggiano
@seldaek :: http://seld.be/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

[Ben Schmidt]

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 : $y in
line with the DRY design principle. A notice would never be emitted
here in any case. The problem is that this idiom is still in wide use
despite the shortcut ternary operator already provided, because an
isset() check is different to a boolean cast.

Some thoughts:

- The actual intent of 2. is probably $x!==null ? $x : $y i.e. it's
not about suppressing notices at all, but about offering a default
value, and the idiom quite probably only uses isset() because it
predated null in the language.


I have never felt the need for a shortcut in these cases. It would be
interesting to see some code where this would be practical.


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();
   }
}

The default value of null indicates that the argument is able to be
omitted, and the type hinting mechanism understands that. Yet it's
awkward to actually test whether it's been omitted or not without
writing the argument multiple times. It'd be great to be able to write
the first line succinctly, e.g.

$bar $:= $this->defaultBar;

That's just one case. There are many more.

As I said above, though, I probably should have written $bar!==null
rather than isset($bar), because I actually would want the warning if
$bar was not defined (i.e. I had mistyped it).


- If we view 2. in this way, the two problems are independent, and it
seems to me it would be best to solve them independently, rather
than with a single operator.

So, I suggest:

1. An array lookup mechanism that suppresses the notice for undefined
keys. It would work the same as regular array index lookups except
that the notice for undefined keys (and only for undefined keys)
would not be generated (it would not just be hidden, but would never
be even generated).


This is what I feel PHP is missing. Particularly when it comes to
multi-dimensional arrays. Because this feature is missing I tend to do
something like

function generateHash($x, $y, $z)
{
return "$x::$y::$z";
}

if (isset($a[generateHash($x, $y, $z)]) {
...
}

instead of

if (isset($a[$x]) && isset($a[$x][$y]) && isset($a[$x][$y][$z])) {
...
}


I don't really understand your example, or how an error-suppressing
array index lookup helps it, but I do think the feature is useful.

I actually think there is enough support for both these things, and
implementing them independently allows those who want to use one but not
the other to do so.


Arguing about syntax is then a second step. However, my views on this
are:


I think it best to avoid discussing the actual syntax before agreeing on what we
really need.


I agree. In fact I sent the previous mail by mistake; I had intended to
archive my thoughts on syntax and send the mail without them, but I
bumped send.

Ben.




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] svn access and working on the firebird bugs: 54426,48447...

[Pierre Joye]

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 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 with vanilla install from source 5.3.x
> Here is the script modified a little to test it on my machine
> http://gist.github.com/286884
>
> tested with both firebird 2.5
> but sometimes crashes
> http://gist.github.com/286887
>
> valgrind --tool=helgrind /opt/php5.3.x/bin/php 48447.php
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] svn access and working on the firebird bugs: 54426,48447...

[Ferenc Kovacs]

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 list
> ...)
>
> One example i work on is
> http://bugs.php.net/48447
>
> Tested with vanilla install from source 5.3.x
> Here is the script modified a little to test it on my machine
> http://gist.github.com/286884
>
> tested with both firebird 2.5
> but sometimes crashes
> http://gist.github.com/286887
>
> valgrind --tool=helgrind /opt/php5.3.x/bin/php 48447.php
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> hi

did you read http://www.php.net/svn-php.php ?

Tyrael

Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

[Ferenc Kovacs]

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.


>
> What we're wanting are existential assignment and ternary operators.
> Simply put, a painless way to set or use a default value based on the
> existence of a variable without needing a bunch of extra code to avoid
> notices/errors. Sorry Ben, but I think extending the @ operator to
> prevent errors from being generated in the first place is a terrible
> idea. I would prefer to see @ removed from PHP if possible.
>
>
> there are cases where you can't write clean code without @.
for example there is an instruction, which can generate an error and you can
predict that it is "safe" to execute or not.
for example:
- 
http://php.net/manual/en/simplexmlelement.construct.php
- http://php.net/manual/en/function.simplexml-load-file.php
which can be worked around with
http://php.net/manual/en/function.libxml-use-internal-errors.php

or another example would be serialize/unserialize:
http://www.php.net/manual/en/function.unserialize.php

it can be a perfectly valid to suppress the notice and check for the return
value of the serialize/unserialize call to handle errors locally.

another example: you have a script, which checks for a cache file, if
present then you simply read it, if not, then you generate the result and
write it to the cache file, which gets invalidated(deleted) if it's older
than x.
but you can't atomically check the existence of the file then read it. and
it can happen (race condition) that you the file was present when you
checked with file_exists, but it is deleted when you try to open it in the
next line.

I think that it could be a good idea to provide an operator to not just
change the error reporting level, but to simply prevent the error
generation.
of course its a tricky question: should we discard the error if an error
handler is registered?

Tyrael

[PHP-DEV] svn access and working on the firebird bugs: 54426,48447...

[marius adrian popa]

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 with vanilla install from source 5.3.x
Here is the script modified a little to test it on my machine
http://gist.github.com/286884

tested with both firebird 2.5
but sometimes crashes
http://gist.github.com/286887

valgrind --tool=helgrind /opt/php5.3.x/bin/php 48447.php

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

[Richard Quadling]

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 variable (or made a
>> typo), I want to know. I don't want to hide it with isset()/empty()
>
> yes and no
>
> $config['modulename'] = array
> (
>  'icon' => 'bla.gif',
>  'default_params' => array
>  (
>  'autocleanup'       => 1,
>  'ignore_user_abort' => 0,
>  )
> );
>
>
> if 'default_params' are optional you NEED isset() to decide
> do something with them or skip operations
>
>

I think that depends upon the developer.

I don't mix the tests for existence.

Mixing the tests means a typo in the isset() will hide the lack of existence.

But array_key_exists() is not going to do that. If the key exists then
I can process it. If not, then I can't.





-- 
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

[Ole Markus With]

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
notices at all unless any of $x $y or $z are not defined, you don't need  
to

check the indexes one by one.



Well, the example was just for brevity. If you want a full-blown example:

if (!isset($a[$x])) {
 $a[$x] = array();
}

if (!isset($a[$x][$y])) {
 $a[$x][$y] = array();
}

if (!isset($a[$x][$y][$z])) {
 $a[$x][$y][$z] = array();
}

$a[$x][$y][$z] = 1;


Hope this clarifies.


--
Ole Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

[Reindl Harald]

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 want to hide it with isset()/empty()

yes and no

$config['modulename'] = array
(
 'icon' => 'bla.gif',
 'default_params' => array
 (
  'autocleanup'   => 1,
  'ignore_user_abort' => 0,
 )
);


if 'default_params' are optional you NEED isset() to decide
do something with them or skip operations



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

[Richard Quadling]

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
> check the indexes one by one.
>
> 2011/4/14 Ole Markus With 
>
>> 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
 variable should not be 'instanciated' before use.

 So
 +1 if this shortcut is implemented to only work for array elements.
 -1 for any other variable type.

>>>
>>> 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. Offering a shortcut for the common idiom isset($x) ? $x : $y in
>>>    line with the DRY design principle. A notice would never be emitted
>>>    here in any case. The problem is that this idiom is still in wide use
>>>    despite the shortcut ternary operator already provided, because an
>>>    isset() check is different to a boolean cast.
>>>
>>> Some thoughts:
>>>
>>>    - The actual intent of 2. is probably $x!==null ? $x : $y i.e. it's
>>>      not about suppressing notices at all, but about offering a default
>>>      value, and the idiom quite probably only uses isset() because it
>>>      predated null in the language.
>>>
>>>
>> I have never felt the need for a shortcut in these cases. It would be
>> interesting to see some code where this would be practical.
>>
>>
>>    - If we view 2. in this way, the two problems are independent, and it
>>>      seems to me it would be best to solve them independently, rather
>>>      than with a single operator.
>>>
>>> So, I suggest:
>>>
>>>    1. An array lookup mechanism that suppresses the notice for undefined
>>>    keys. It would work the same as regular array index lookups except
>>>    that the notice for undefined keys (and only for undefined keys)
>>>    would not be generated (it would not just be hidden, but would never
>>>    be even generated).
>>>
>>
>> This is what I feel PHP is missing. Particularly when it comes to
>> multi-dimensional arrays. Because this feature is missing I tend to do
>> something like
>>
>> function generateHash($x, $y, $z)
>> {
>>  return "$x::$y::$z";
>> }
>>
>> if (isset($a[generateHash($x, $y, $z)]) {
>>  ...
>> }
>>
>> instead of
>>
>> if (isset($a[$x]) && isset($a[$x][$y]) && isset($a[$x][$y][$z])) {
>>  ...
>>
>> }
>>
>> Arguing about syntax is then a second step. However, my views on this
>>> are:
>>>
>>>
>> I think it best to avoid discussing the actual syntax before agreeing on
>> what we really need.
>>
>> --
>> Ole Markus With
>> Systems Architect - Sportradar AS
>> Developer - Gentoo Linux
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>

http://news.php.net/php.internals/51877

array_key_exists($key, $array) for arrays
array_key_exists($varname, get_defined_vars()) for locally scoped variables.

No need to use @.

isset() and empty() will not differentiate between an undefined
variable or index and a variable or an array element which is assigned
null.

The E_NOTICE only ever gets fired for the undefined variable/key ...

Notice: Undefined variable
Notice: Undefined index


I think it depends upon the developer's requirement.

Are they attempting to determine the existence of a variable/index
entry or are they attempting to determine if the variable/element is
null.

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 want to hide it with isset()/empty().




-- 
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

[Eloy Bote Falcon]

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 <
> 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
>>> variable should not be 'instanciated' before use.
>>>
>>> So
>>> +1 if this shortcut is implemented to only work for array elements.
>>> -1 for any other variable type.
>>>
>>
>> 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. Offering a shortcut for the common idiom isset($x) ? $x : $y in
>>line with the DRY design principle. A notice would never be emitted
>>here in any case. The problem is that this idiom is still in wide use
>>despite the shortcut ternary operator already provided, because an
>>isset() check is different to a boolean cast.
>>
>> Some thoughts:
>>
>>- The actual intent of 2. is probably $x!==null ? $x : $y i.e. it's
>>  not about suppressing notices at all, but about offering a default
>>  value, and the idiom quite probably only uses isset() because it
>>  predated null in the language.
>>
>>
> I have never felt the need for a shortcut in these cases. It would be
> interesting to see some code where this would be practical.
>
>
>- If we view 2. in this way, the two problems are independent, and it
>>  seems to me it would be best to solve them independently, rather
>>  than with a single operator.
>>
>> So, I suggest:
>>
>>1. An array lookup mechanism that suppresses the notice for undefined
>>keys. It would work the same as regular array index lookups except
>>that the notice for undefined keys (and only for undefined keys)
>>would not be generated (it would not just be hidden, but would never
>>be even generated).
>>
>
> This is what I feel PHP is missing. Particularly when it comes to
> multi-dimensional arrays. Because this feature is missing I tend to do
> something like
>
> function generateHash($x, $y, $z)
> {
>  return "$x::$y::$z";
> }
>
> if (isset($a[generateHash($x, $y, $z)]) {
>  ...
> }
>
> instead of
>
> if (isset($a[$x]) && isset($a[$x][$y]) && isset($a[$x][$y][$z])) {
>  ...
>
> }
>
> Arguing about syntax is then a second step. However, my views on this
>> are:
>>
>>
> I think it best to avoid discussing the actual syntax before agreeing on
> what we really need.
>
> --
> Ole Markus With
> Systems Architect - Sportradar AS
> Developer - Gentoo Linux
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator

[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 'instanciated' before use.

So
+1 if this shortcut is implemented to only work for array elements.
-1 for any other variable type.


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. Offering a shortcut for the common idiom isset($x) ? $x : $y in
line with the DRY design principle. A notice would never be emitted
here in any case. The problem is that this idiom is still in wide use
despite the shortcut ternary operator already provided, because an
isset() check is different to a boolean cast.

Some thoughts:

- The actual intent of 2. is probably $x!==null ? $x : $y i.e. it's
  not about suppressing notices at all, but about offering a default
  value, and the idiom quite probably only uses isset() because it
  predated null in the language.



I have never felt the need for a shortcut in these cases. It would be  
interesting to see some code where this would be practical.



- If we view 2. in this way, the two problems are independent, and it
  seems to me it would be best to solve them independently, rather
  than with a single operator.

So, I suggest:

1. An array lookup mechanism that suppresses the notice for undefined
keys. It would work the same as regular array index lookups except
that the notice for undefined keys (and only for undefined keys)
would not be generated (it would not just be hidden, but would never
be even generated).


This is what I feel PHP is missing. Particularly when it comes to  
multi-dimensional arrays. Because this feature is missing I tend to do  
something like


function generateHash($x, $y, $z)
{
 return "$x::$y::$z";
}

if (isset($a[generateHash($x, $y, $z)]) {
 ...
}

instead of

if (isset($a[$x]) && isset($a[$x][$y]) && isset($a[$x][$y][$z])) {
 ...
}


Arguing about syntax is then a second step. However, my views on this
are:



I think it best to avoid discussing the actual syntax before agreeing on  
what we really need.


--
Ole Markus With
Systems Architect - Sportradar AS
Developer - Gentoo Linux

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php