Newsgroups: php.internals,php.internals Path: news.php.net Xref: news.php.net php.internals:84407 php.internals:84408 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 9065 invoked from network); 7 Mar 2015 17:12:28 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Mar 2015 17:12:28 -0000 X-Host-Fingerprint: 78.217.8.218 gaz43-2-78-217-8-218.fbx.proxad.net Received: from [78.217.8.218] ([78.217.8.218:15777] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 91/D1-29230-9713BF45 for ; Sat, 07 Mar 2015 12:12:26 -0500 To: internals@lists.php.net,Yasuo Ohgaki , Pierre Joye Message-ID: <54FB3175.3000308@luni.fr> Date: Sat, 07 Mar 2015 18:12:21 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 CC: Arvids Godjuks , Rowan Collins , "internals@lists.php.net" , Larry Garfield References: <1FCB68B8-3E55-4B5D-B805-9D92D848A3A1@gmail.com> <5D8591E2-5AE6-4B4C-AAE0-3D15523410AC@gmail.com> <54F83C4D.1020206@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Posted-By: 78.217.8.218 Subject: Re: [PHP-DEV] Consistent function names From: gregory@luni.fr (=?UTF-8?B?R3LDqWdvcnkgUGxhbmNoYXQ=?=) Le 07/03/2015 02:39, Yasuo Ohgaki a écrit : > We may provide new names and new parameter order in new namespace. > The difference is "alias" or "namespace" basically. I don't object to use > namespace for it at all. In fact, I would love to have it even if there is > issue > like writing extremely difficult to read code is possible. Hello all, I join the thread as a seasoned PHP developer (in user-space), not as a PHP core developer. I work since 6 years now for large companies websites and I write PHP scripts and programs since 15 years now. I would like to bring my brick to this wall. I follow the thread since a few days now and I have some suggestion which can resolve both the functions naming issue for some of you, some others suggested to have an object-oriented API and some are fearing massive BC breaks. I read Larry Garfield and Pierre Joye suggesting the idea of an object-oriented API, maybe others suggested it already as long as this idea is running here since a few years. I wrote these days the start of a spec of an API, it is far from being finished for the scalar types but the array part is almost finished and integrates every method documented in the current array API. https://github.com/gplanchat/php-oop-api Suggestions are welcome, you can fork and comment. I don't have the ambition to rewrite all the PHP core, but just using the existing underlying code and applying it a new interface in the userspace. Additionally to the current API. I use the ideas from the [PECL SPL types extension](http://php.net/manual/en/book.spl-types.php) and Nikita Popov's [scalar objects extension](https://github.com/nikic/scalar_objects). Those enhancements could be part of one RFC or several, as the amout of work can be massive. The essential point is that this refactoring *MUST* be using only existing code in the core. It *SHOULD* make it appear differently to the user. The risk is then lower than a full refactoring. It is, IMHO, the best compromise for the entire PHP community. There are several goals and possibilities behind this : * Create a consistent and complete API that can satisfy OOP programmers and give them a more powerful API * Do not create BC breaks on these core types, the ZVAL struct is unchanged and the IS_STRING, IS-DOUBLE, ect... are still used as usual * Make it possible in a future release (let's say PHP 8, 9 or 10+) to deprecate and even remove the old API * Build easily encoding-aware strings (binary, ASCII, UTF-8, UTF-16BE, UTF-16BE, UTF-32, JIS, Big5, ect...) Thanks for reading. Grégory Planchat