Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61593
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.163 as permitted sender)
Message-ID: <5009E557.1090906@sugarcrm.com>
Date: Fri, 20 Jul 2012 16:10:15 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Matthew Weier O'Phinney <weierophinney@php.net>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <CAOhuFvYD8FQw=xbK3hFqi4GYkOvCNzWjuhk2fqwBjKG9n2kuuQ@mail.gmail.com> <CAAyV7nEpp+Srxemgi913K2nZ7rztz6RV-9bNdXdPJx49q-AenQ@mail.gmail.com> <CA+Ky_uMV5nPmGZPktJ1a6XeYU68Zq=axbaZqMX0Te8D2CE9FGw@mail.gmail.com> <CA+Ky_uNs7tWy9AHma-1zgxKnNTdTe2FHqGm0Tmip9Awc=pqfAw@mail.gmail.com> <FE.FF.18983.B5BD9005@pb1.pair.com>
In-Reply-To: <FE.FF.18983.B5BD9005@pb1.pair.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Implicit isset in ternary operator
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> Top-posting, as not sure where to snip. :)
> 
> I think either "??" "??:" as an operator makes sense, and would be
> readable and easy to learn, and resolve any BC concerns people have. I'd
> love to see this in, as the current behavior is basically useless for me
> I don't think I've once had code where I could successfully use it
> without worrying about the E_NOTICE, which then forces me to use the
> longhand form. Having a version that does an implicit "isset" would be
> tremendously useful.

I think we've painted ourselves into a corner somewhat here, because we
have the following things clashing:
1. Producing an error when accessing non-existing var/element.
2. Unability to temporarily disable 1 since @ both is regarded as
"unclean" and does not actually disable the error generation, only makes
it not printed out.
3. Obvious need to express common pattern "take it if it exists, assume
null if it does not".

Note that the case in 3 is not limited to ?: in any way, you as
frequently encounter it in any context where you can encounter a
variable. We can get back to ?: if we extend 3 with "take it if it
exists, assume this other value if it does not" - but we don't have to,
as the use case is completely dominated by "null" pattern, it is very
rare that you need any other default than null and type conversions of
null like ''/false/0.

I'd be very happy if we could have something like @$var['foo'] just work
by not generating any errors, but if not then probably having some
syntax saying "this variable or null, no notices" will be good - if say
it's $?foo then we could easily add defaults by doing $?foo ?: 'bar'.
Making @$var magically work though would have an advantage of being
instantly backwards compatible.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227