Re: Implicit isset/isempty check on short-ternary operator

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 <mail_ben_schmidt@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 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 > >