Hi Gregory, On Sun, Mar 8, 2015 at 7:03 PM, Grégory Planchat <greg...@luni.fr> wrote:
> Le 08/03/2015 00:44, Yasuo Ohgaki a écrit : > > Hi Gregory, >> >> On Sun, Mar 8, 2015 at 2:12 AM, Grégory Planchat <greg...@luni.fr> 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. > Procedural API should exist forever. IMO. > 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. > I've already made UTF-8 as default PHP encoding by https://wiki.php.net/rfc/default_encoding Mixing encoding is nice and flexible, but it would make implementation more complex. It many cases needlessly. UTF-8 is standard now a days, so it would be the most reasonable choice for the default. Problem is Unicode has many forms for "a character", has many ways to "compare" them. For example, MySQL has utf8_general_ci and utf8_unicode_ci. utf8_unicode_ci is just unusable with Japanese because it treats "パパ"(father) and "ハハ"(mother) as the same string. We may have many ways to compare strings, but the default should be the most reasonable one and string should be encoded so that simple byte by byte could be done to check equality if it's possible. There are enough complex things in Unicode only, adding multiple default encoding support may not worth it. > 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. > I agree that these basic OO feature should be consistent with procedural APIs. I don't object to have $str->indexOf(5)/$str->length()/etc, but almost all of basic OO API should reflect procedural API. 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()? > I meant "array", "scalar" related functions. > > > 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. > Newcomers will not be confused if they lookup new manual. There will be only main function listed and aliases are mentioned as "valid" function names unless we decide deprecate it. There is nothing wrong to use old names because they are valid and good names for them. > 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 > IEEE/C lib names exist as standard violating names currently. My RFC will make them "valid" and part of "standard". I don't think deprecating IEEE/C lib name functions is not good idea at all. Making them standard, or at least exceptions, seems only reasonable resolution for this. IMO. > 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. > Why hazardous? Old names are kept as valid function names, only new consistent names are introduced. I've renamed pg_loopen() (and like) to pg_lo_open() about 10 years ago. http://php.net/pg_lo_open I didn't get even single compliant for this from users. (I'm one of a director of Japanese PostgreSQL Users Group and know many PostgreSQL and PHP users) Programmers are used to refactoring and renaming today and old names will never removed unless there are good reasons to remove. I don't see any reasons to be hazardous. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
