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

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 <mail_ben_schmidt@yahoo.com.au <mailto: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