Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51880
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain yahoo.com.au from 98.139.52.221 cause and error)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com.au;
  h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
  b=09y8VM9T6y0vU+VRUZYqE2xGrffzYw1fqyoUhZdowXKJ5djv2+pKTpWaXm5ly7P2A5x30RJYToA3bYqrKsA1909c2n20Xw0nsa9i05E3SEYiQy2C1eAjVr+kjaBwwrNwAf9fFemwZeHTM7cjgS+jJv+J3IBOE0xHeepCPI9j360=  ;
Message-ID: <4DA63ED8.4080402@yahoo.com.au>
Date: Thu, 14 Apr 2011 10:24:56 +1000
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 ThunderBrowse/3.3.5
MIME-Version: 1.0
To: Ole Markus With <olemarkus@olemarkus.org>,
  "internals@lists.php.net" <internals@lists.php.net>
References: <AANLkTiknomAsTrsZ140rWs6CwxJP3UYGUokQbERhDiRp@mail.gmail.com> <4D950434.3060704@yahoo.com.au> <BANLkTinzb5xiD8j7ZXB+cT4EBZY3DF6BYQ@mail.gmail.com> <4D9E0543.1080600@lerdorf.com> <69.82.36433.EC33E9D4@pb1.pair.com> <4D9E34C4.5000406@lerdorf.com> <4D9E429B.20503@sugarcrm.com> <4D9E96B6.6060401@lerdorf.com> <BANLkTi=LvYLaOoGgrzrWfYbQ+t9Wzv_XeQ@mail.gmail.com> <BANLkTim6ZBWw66rzx_gSvWc9E45EZx2_gw@mail.gmail.com> <BANLkTinxG6FtOqa8KzmvgTT1EFfM-6prow@mail.gmail.com> <BANLkTinsnqGSVTz=XPhCfX95mfeJ_pkhCg@mail.gmail.com> <BANLkTi=nwij4sfkKnNdM_NP9w2CArK6NHQ@mail.gmail.com> <BANLkTikghRix9VbpHDx+rnCRtnjdjeshmg@mail.gmail.com> <718216446.20110408143441@cypressintegrated.com> <4DA0E71C.9030008@gmail.com> <BANLkTi=jJTO3qgjN8=3DCKAV88pnvycVsA@mail.gmail.com> <op.vtp8l9jnr8a5bd@localhost>
In-Reply-To: <op.vtp8l9jnr8a5bd@localhost>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
From: mail_ben_schmidt@yahoo.com.au (Ben Schmidt)

> 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.