Newsgroups: php.internals,php.internals Path: news.php.net Xref: news.php.net php.internals:84429 php.internals:84430 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 84603 invoked from network); 8 Mar 2015 10:03:27 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 Mar 2015 10:03:27 -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:7292] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 36/50-17427-B6E1CF45 for ; Sun, 08 Mar 2015 05:03:24 -0500 To: internals@lists.php.net,Yasuo Ohgaki Message-ID: <54FC1E67.3070504@luni.fr> Date: Sun, 08 Mar 2015 11:03:19 +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: "internals@lists.php.net" , Pierre Joye , Arvids Godjuks , Rowan Collins , Larry Garfield References: <5D8591E2-5AE6-4B4C-AAE0-3D15523410AC@gmail.com> <54F83C4D.1020206@gmail.com> <54FB3175.3000308@luni.fr> 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=?=) Hi Yasuo, Le 08/03/2015 00:44, Yasuo Ohgaki a écrit : > Hi Gregory, > > On Sun, Mar 8, 2015 at 2:12 AM, Grégory Planchat wrote: > >> 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. >> > > Nice post indeed! I'll insist to keep procedural API, though :) The point wasn't about deleting the procedural API now. I just mentioned it was a possibility, I meant at the (very) long term that this API could be deprecated or deleted, but it is not a mandatory rule. If this appears to happen someday, it will be done after 5 or even 10 years following PHP 7.0 release and when a very large majority of projects has migrated to PHP 7 *AND* this possible new API. There will posibly be some who prefer OO and others procedural and both could cohabit indefinitely. > We are better to have unified encoding for simplicity. Multibyte string > comparison is > complex, so it's better to have NFC/NFG normalized UTF-8 strings as the > default. > Other encodings can be supported as conversions. I have no personal preference for a specific default encoding as long as it is portable and widely used (UTF-8 seems to be the standard nowadays by the way). I have though a preference for an unified API for all strings values, either they are managed by the standard API or mbstring or which ever specific extension you plan to use. This is - I think - the most important point, changing the default encoding could then become a detail (or be defined in php.ini). Then using multiple encodings in a same script or using a same script for multiple encodings becomes straightforward and standard. Most PHP developers doesn't even know what is Unicode or a character encoding, they just see "odd characters that are removed with a header() call or utf8_decode()", no teasing intended, they just don't want to have to handle this. PHP should not let this sort of consideration to the sole awareness of user-space developers. > We are better to have consistency between procedural functions and OO > methods > where it is possible. I see a few inconsistencies like "hasKey", "has", > "recursiveWalk". > These names could be adjusted by function and/or method. Yes, that's the point of my message, if some method names or parameter orders seems inconsistent to you, let's talk about it and make it more concistent. I also may have made mistakes or oversight witing it. But one thing seems important to say, the docs I wrote do not map to existing procedural API names and parameter order, as this API is not concistent with itself. To be remembered that this OO API does not use classic objects, it is syntaxic sugar over existing scalar, array and string types. > This RFC could be made so that it leaves space for consistency. i.e. Do not > touch > variable related functions to have consistent names for both procedural > functions and > OO methods in the future. I don't understand what you mean with "variable related functions", are you talking about functions like list() and compact()? > Or we may discuss/adjust consistency fully. The change may be introduced > PHP 7.x or even PHP 8. We may take time as long as it takes and have votes > for multiple RFCs that have consistent names/parameters at once. > > The latter is better choice. IMO. As some mentioned in the thread, adding aliases to the current API will have 2 main consequences * create confusion for newcomers, that will not understand why there are 2 names for one function * it will be difficult to impose to seasoned developers, as they shall prefer to not change and keep a relatively backward-compatible code base instead of having to maintain 2 code bases. Also, making all existing projects use this new API will take time, I remember the release of PHP 5.0 and PHP 5.1 that was at this time bothly not availiable on most shared hostings and not supported by most projects (or as a rough PHP 4 port). Additionally, as Rasmus mentioned, lots of methods names are mappings to the extension's underlying C API or responding to an IEEE standard. Some of us are used to C development and their underlying APIs and found it easier to have a simple mapping between languages. Changing evrything now would just create a Python 3 effect IMHO, even if I agree that it looks like confusing nowadays for newcomers, 20 years after the first releases of PHP. Adding an OO API is a compromise, every developer/team would use one or the other for his own reasons. I think that in a long term > My objective with this RFC is to make sure to have consistent procedural > function names "someday" so that PHP will have nice and consistent > procedural > functions forever. I understand and, as I wrote above, this will have a big impact on the userbase, with consequences that are not measurable now. Maybe this could be done with a new language, but as PHP is now old of a couple decades and has multiple engines (HHVM, Phalanger, Quercus, Parrot, ect...), making this move is very hazardous. I think that's the point Rasmus, Larry Garfield, Pierre Joye and others did have in mind, out of the pure beauty of code. Regards, Grégory Planchat