Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:61411 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 16693 invoked from network); 18 Jul 2012 16:35:13 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Jul 2012 16:35:13 -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.193 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.193 smtp193.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.193] ([67.192.241.193:55207] helo=smtp193.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 59/60-39169-FB5E6005 for ; Wed, 18 Jul 2012 12:35:13 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp19.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 88FFE3C81A7; Wed, 18 Jul 2012 12:35:09 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp19.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 2CEDC3C80FA; Wed, 18 Jul 2012 12:35:09 -0400 (EDT) Message-ID: <5006E5BB.50906@sugarcrm.com> Date: Wed, 18 Jul 2012 09:35:07 -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: Andrew Faulds CC: Pierre Joye , internals References: <50059AF8.5050805@sugarcrm.com> <5005CB58.2020601@sugarcrm.com> <50066724.6050901@sugarcrm.com> <50067040.3090307@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.) From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > enough but I don't know the Zend engine well enough). This way we can > have array->key, array->sort(TYPE), etc. for new code to use, instead of > the legacy array and string method mess (the latter needs a cleanup more > in particular). The mess does not exist because we have array_key() instead of array->key(). There's nothing wrong with having array_key(). The mess exists because functions do not form single API with single principle behind it, but were added in ad-hoc manner, sometimes without correlating them with others. So, if you want to clean it up, you'd want to write a plan how new API would look like and how it will be better than old one. If the solution is "let's use ->" then it's not worth it. The solution that's worth it is "let's have this better API" and that's where we should start, not with changing array_key() to array->key() and saying "now we have clean sexy API". -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227