Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:61503 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 16826 invoked from network); 19 Jul 2012 17:39:46 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Jul 2012 17:39:46 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.173 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.173 smtp173.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.173] ([67.192.241.173:56039] helo=smtp173.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 81/B6-18983-F5648005 for ; Thu, 19 Jul 2012 13:39:44 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp7.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 8CC30258503; Thu, 19 Jul 2012 13:39:41 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp7.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id DAFC8258533; Thu, 19 Jul 2012 13:39:40 -0400 (EDT) Message-ID: <5008465C.4090200@sugarcrm.com> Date: Thu, 19 Jul 2012 10:39:40 -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: Pierre Joye CC: Rasmus Lerdorf , internals References: <50059AF8.5050805@sugarcrm.com> <5005CB58.2020601@sugarcrm.com> <50066724.6050901@sugarcrm.com> <50070538.10206@lerdorf.com> <50082C7E.4080400@lerdorf.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.) From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > So we should better begin to see where are the technical bottlenecks > and figure out a way to solve them instead of arguing about whether we > should do it or not. Because we will have to do it, whether we like it > or not. No, that's exactly WRONG way to do things. We should first know if it's good for PHP and only AFTER we know it's good, we should look for technical bottlenecks. Doing it the wrong way is exactly what got us in situation that everybody recognizes is messy. Because stuff that was technically possible (and some things that only seemed possible if you don't think too hard about them) was done without thinking how it would behave in all the situations and how the rest of the language would work with it. What I do find a bit disturbing is that you think "I know some people that want it" is a good argument to implement any language feature despite quite clear problems that were explained to you - that you think this argument alone is enough to dismiss all these problems as if they didn't exist. You just wave it away and then you are surprised - where this resistance is coming from? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227