Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63651
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.131 as permitted sender)
Message-ID: <508AA48D.5010903@sugarcrm.com>
Date: Fri, 26 Oct 2012 16:56:13 +0200
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Clint Priest <cpriest@zerocue.com>
CC: PHP Developers Mailing List <internals@lists.php.net>
References: <508A68B9.1050801@zerocue.com>
In-Reply-To: <508A68B9.1050801@zerocue.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable"
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

>  1.      If all cases can be tested for during compilation, prefer
>     compile failures.

Not likely. isset($foo->$bar) is completely opaque since we don't know
what $foo or $bar is.

>  2.      Let the compilation occur and at runtime when a disallowed
>     action is attempted, emit a warning and move on.
>  3.      As is currently, either at compilation or at runtime we issue a
>     fatal error and stop execution (probably least preferable if at runtime)

Actually, I think the right way is:

4. On isset(), if the value can be retrieved, return true. Otherwise,
return false (including the case when the value can not be retrieved
because of missing getter). Same holds for empty() but in reverse - if
isset() would return false, it'd return true and vice versa.
On unset($foo->bar), act exactly as if the code were $foo->bar = NULL;

Of course, this applies only for automatic definition of isset/unset.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227