Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:63667 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 43965 invoked from network); 27 Oct 2012 17:52:25 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Oct 2012 17:52:25 -0000 Authentication-Results: pb1.pair.com header.from=cpriest@zerocue.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=cpriest@zerocue.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zerocue.com designates 67.200.53.250 as permitted sender) X-PHP-List-Original-Sender: cpriest@zerocue.com X-Host-Fingerprint: 67.200.53.250 mail.zerocue.com Received: from [67.200.53.250] ([67.200.53.250:51394] helo=mail.zerocue.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A5/9B-51104-55F1C805 for ; Sat, 27 Oct 2012 13:52:25 -0400 Received: from [172.17.0.122] (unknown [72.179.52.187]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.zerocue.com (Postfix) with ESMTPSA id 7F9EA120382 for ; Sat, 27 Oct 2012 17:52:19 +0000 (UTC) Message-ID: <508C1C4F.6060406@zerocue.com> Date: Sat, 27 Oct 2012 12:39:27 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: internals@lists.php.net References: <508A68B9.1050801@zerocue.com> <508AA48D.5010903@sugarcrm.com> In-Reply-To: <508AA48D.5010903@sugarcrm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Property Accessors v1.2 : isset / unset "failable" From: cpriest@zerocue.com (Clint Priest) That's basically what #2 is getting at, my only question is, emit a warning or notice or not? Technically returning false on an invalid isset() call could be misleading without emitting some kind of notice or warning about it. On 10/26/2012 9:56 AM, Stas Malyshev wrote: > 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. -- -Clint