Martin Scotta
On Thu, Apr 14, 2011 at 8:58 AM, Ben Schmidt
<mail_ben_schm...@yahoo.com.au>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
>
>
