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:

   - Changing the existing behaviour of the ternary or shortcut ternary
     operator is a bad idea. Good arguments have been offered against
     it.

   - 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).

   2. A shortcut for $x!==null ? $x : $y.

This allows people to opt out of either feature if they don't want it,
and doesn't encourage poor coding by suppressing warnings for undefined
variables.

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

   1. Since we have @ meaning error-suppression already, why not reuse
   that symbol, in a location that is unambiguous? $array@[$key] would
   achieve this, right? It is localised to a single lookup, so can be as
   precise as the coder wants. E.g. one could do
   $array@["maybe-missing"]["expected"]@["maybe-missing"] and there's no
   ambiguity about what is meant. Nesting is likewise unambiguous, so in
   $array@[$lookups["key"]] if "key" does not exist, we still get a
   notice.

   2. We just need a single symbol, probably with multiple characters.
   The key thing omitted by the shortcut is !==null so something that
   evokes that would be a good choice. Two possibilities are using
   something involving ? as in the ternary operator, or | as in the
   logical short-circuiting or operator. E.g. we could have $x ??: $y or
   $x ||| $y. However, both these somewhat imply either boolean tests or
   boolean results, which would be best to avoid. This is not about
   error suppression, so using @ would be unwise. Perhaps the best
   character to use is $ because $ somewhat represents a variable. So
   perhaps a good syntax would be $x $: $y. The $ somewhat evokes to me
   'use the variable if you can (it is not null)' and the : somewhat
   evokes 'otherwise', so I think it captures the meaning of the
   operator.

In combination (which some people probably want), this looks like
$array@["key"] $: "default"

It's a bit different to what we're used to seeing, but the syntax is (1)
sensible and evocative of the right interpretation, and (2) not
misleading. I'd rather see something I'm unsure about and drives me back
to the docs than something that misleads me.

Ben.




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

Reply via email to