Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:61948 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 66495 invoked from network); 2 Aug 2012 07:16:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Aug 2012 07:16:24 -0000 Authentication-Results: pb1.pair.com header.from=swhitemanlistens-software@cypressintegrated.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=swhitemanlistens-software@cypressintegrated.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain cypressintegrated.com designates 69.28.242.152 as permitted sender) X-PHP-List-Original-Sender: swhitemanlistens-software@cypressintegrated.com X-Host-Fingerprint: 69.28.242.152 rproxy1-a.cypressintegrated.com Received: from [69.28.242.152] ([69.28.242.152:2271] helo=rproxy1-a.cypressintegrated.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F3/B2-48311-7492A105 for ; Thu, 02 Aug 2012 03:16:23 -0400 Received: from localhost ([192.168.87.152]) by rproxy1-a.cypressintegrated.com (Brand New Heavy v1.0) with ASMTP id MPS39822 for ; Thu, 02 Aug 2012 03:16:22 -0400 Date: Thu, 2 Aug 2012 03:15:38 -0400 Reply-To: Sanford Whiteman X-Priority: 3 (Normal) Message-ID: <28857339.20120802031538@cypressintegrated.com> To: Christoph Hochstrasser In-Reply-To: <1708AB78DAB340DC8C8D7F54F652EBBF@gmail.com> References: <5009E557.1090906@sugarcrm.com> <1708AB78DAB340DC8C8D7F54F652EBBF@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Implicit isset in ternary operator From: swhitemanlistens-software@cypressintegrated.com (Sanford Whiteman) So... I was thinking of proposing that we perhaps leave Arrays as is w/r/t undefined indices, while fixing up the ArrayObject gaps and making that the "smart" one (wrap/box in an AO if you want expanded/overloadable functionality). That idea was based on my belief that ArrayObject::offsetGet already failed gracefully, from the docs: "Returns: The value at the specified index or FALSE." Don't think so. Seems like it returns NULL and fires a notice as with an array. Doc bug I guess, as as returning FALSE would be pretty ambiguous. -- S.