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 '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.
I cry whenever I see code with @ in it... > > 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. > > 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 like Rune's proposal, although I'd prefer ?= for the assignment operator instead of ??= 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. Cheers, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
