Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:48692 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 65294 invoked from network); 8 Jun 2010 15:28:43 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 Jun 2010 15:28:43 -0000 Authentication-Results: pb1.pair.com header.from=brian@moonspot.net; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=brian@moonspot.net; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain moonspot.net designates 72.5.90.27 as permitted sender) X-PHP-List-Original-Sender: brian@moonspot.net X-Host-Fingerprint: 72.5.90.27 smtp.dealnews.com Linux 2.5 (sometimes 2.4) (4) Received: from [72.5.90.27] ([72.5.90.27:56703] helo=smtp.dealnews.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A5/E0-13782-9A16E0C4 for ; Tue, 08 Jun 2010 11:28:43 -0400 Received: (qmail 5075 invoked from network); 8 Jun 2010 15:28:31 -0000 Received: from unknown (HELO mail.dealnews.com) (10.1.10.7) by -H with ESMTPS (DHE-RSA-AES256-SHA encrypted); 8 Jun 2010 15:28:31 -0000 Received: (qmail 24985 invoked from network); 8 Jun 2010 15:28:38 -0000 Received: from h105.248.18.98.static.ip.windstream.net (HELO macdough.local) (brianm@98.18.248.105) by -H with ESMTPA; 8 Jun 2010 15:28:38 -0000 Message-ID: <4C0E61A6.7090604@moonspot.net> Date: Tue, 08 Jun 2010 10:28:38 -0500 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Peter Lind CC: "Ford, Mike" , internals References: <2C70277E-0442-49B8-AD0B-E9F12ED7B42C@oettinger.dk> <1275993681.2243.10.camel@guybrush> <93ED589E60BA254F97435FE6C97F2C670A96E32C@leedsmet-exch1.leedsmet.ac.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Array Dereferencing From: brian@moonspot.net (Brian Moon) > The operator that really determines this is 'new' - which is already > documented. So there isn't any ambiguity. Not to say that documenting > the other operators would be bad, just saying there's no ambiguity > here :) > Also, allowing "new (blah());" would be a fairly big BC break I'd say. How? Maybe you don't understand what BC break means. Currently, new ( produces a parse error. So, no old code would ever be broken. That is what a BC break is. A change to the system that breaks old code. New code very often does not run on older versions of the parser. Of course I think all this chaining stuff is for really really lazy people that have more time to worry about the how cool their code looks and don't have real jobs that actual require them to get things done. =) Brian. "In my day!"