Hi Rowan, On Fri, Mar 6, 2015 at 5:41 AM, Rowan Collins <rowan.coll...@gmail.com> wrote:
> Yasuo Ohgaki wrote on 05/03/2015 20:20: > >> Hi Arvids, >> >> On Thu, Mar 5, 2015 at 9:32 PM, Arvids Godjuks <arvids.godj...@gmail.com >> <mailto:arvids.godj...@gmail.com>> wrote: >> >> 2015-03-05 13:49 GMT+02:00 Pierre Joye <pierre....@gmail.com >> <mailto:pierre....@gmail.com>>: >> > >> > >> > I will say it again a last time, in my opinion only a clean API; >> > object-like or real object as long as performance is not affected is >> > the only way I could see to actually solve this problem. >> > >> > Changing the names, argument order (pointless once we will have >> named >> > arguments, btw) and similar solutions are band aids solutions, >> > confusing at best, terrible at worst. It is pointless to do it after >> > almost two decades for some of them. >> > >> > -- >> > Pierre >> > >> > I'm with Pierre here. >> Adding aliases is gonna mess up things even more. For example - >> autocomplete will become hard to navigate. It's already quite >> lengthy list >> a lot of the times and it's easier just to write the whole >> function name >> sometimes by hand. Adding aliases will make it worse. >> >> >> I agree. Therefore, I'm going to update manual also so that it recommends >> main function, not aliases. Aliases should be alternative. >> >> Manual and IDE don't have to list all of them. New manual lists only main >> functions, does not have dedicated pages for aliases but aliases are >> mentioned >> in main function page as aliases. >> > > > You can't fix everyone's IDEs for them. You can't fix all the > documentation (tutorials, blogs, Q&As) not hosted on php.net. Most of > all, you can't fix the thousands of projects already written in PHP using > the "wrong" function names, most of which will want to *continue* using > those function names, because that will be internally consistent, and > portable between versions. > > The problems people are pointing out are not ones that you can promise to > fix. > The same argument applies to OO API alternative. It's impossible update documents/etc to use new OO API as you mentioned. My proposal only requires simple replace. Even simple replace would not be needed since old names work as should be. Users can know what's the main function by looking up manual. It does not seem new OO API will do better job as it may have completely different method names and syntax. > > > > >> We really need a new API, that is not crossing paths with the old. >> That way >> people can start building stuff on new API's and we could phase >> out the old >> mess, for example: depricate in PHP8, remove in PHP9. >> Stop-gap measures have created enough problems already, or did >> everyone >> suddenly got an amnesia and forgot all the past lessons on the list? >> >> >> PHP should be multi paradigm language, not pure OO language. >> IMO. Python does good job. >> > > > The paragraph you are replying to says "new API". It does not say "pure > OO". As I've said before, the relevance of scalar methods is not that > objects are cool and functions are boring; it's that they're something new > we can design from scratch without worrying about the 20 years of legacy > the existing API has. > I'm against making procedural API legacy so that someone would not propose "Let's discard legacy, messy and inconsistent procedural API at all" We should keep good procedural API forever. Procedural API has good set of well defined API such as IEEE 1003.1. PHP also defines good set of procedural APIs. These APIs do not need radical changes, but only small improvement and adjustment is enough like this RFC proposes. (I'll add parameter order issue handling proposal later) > > > > I finally understand why some of us against this change and suggest OO >> APIs >> as alternative. It's reasonable making procedural APIs a >> legacy/unmaintained/ >> messed up to discard procedural APIs someday. I'm against it. PHP should >> be like Python in this regard. IMO. >> > > > OK, so let's look at our options to maintain the language as > multi-paradigm: > > 1) Implement piecemeal tweaks to the current API, adding to the confusion > of users, in the hope that eventually we accumulate enough fixes, everyone > gets used to them, the old ones die away somehow, and the result is a > slightly nicer set of functions, with various awkward compromises along the > way. > I'm going to adopt your suggestions. One is parameter ordering which have been issue for a long time. I'll address this issue with this RFC. ========== $needle should be 2nd argument like int strpos ( string $haystack , mixed $needle [, int $offset= 0 ] ) string stristr ( string $haystack , mixed $needle [, bool $before_needle = false ] ) Rasmus suggested to have IEEE 1003.1 compliance. I like the idea and I'll add this in the RFC, probably. These are the order of parameters. So array functions are subject to be changed. bool in_array ( mixed $needle , array $haystack [, bool $strict ] ) Renamed to array_in() and fix order. mixed array_search ( mixed $needle , array $haystack [, bool $strict ] ) Renamed to array_find() and fix order. bool array_key_exists ( mixed $key , array $array ) Renamed to array_key_find() and fix order. array array_keys ( array $array [, mixed $search_value [, bool $strict = false ]] ) OK as it is now. implode() may be changed to have string implode ( string $glue , array $pieces ) always. =========== As I mentioned, small improvements and adjustments would be enough to keep procedural APIs forever. If my proposal is not good enough to keep procedural API for good, please suggest what's missing. 2) Find a way of designing a clean-break new API which is still procedural. > More than just a namespace, which is basically just some new names with \ > in; and definitely not something where the same code can mean a different > thing depending on a setting or import at the top of the file. Something > which will feel fresh, which users will want to start using, and will > recognise when they see code using it. > I probably don't understand well what you meant here. If we have default namespace to be imported to "\" namespace and user could choose which names to import, we have zero BC for completely new APIs for both OO and procedural APIs. (We have a beast, constants defined by define(), though) I'm not suggesting radical improvement for procedural APIs. Both PHP and IEEE procedural APIs are well established. Only small modifications are needed, IMO. > I don't what that might look like, but if you have some ideas, that is how > you will move this discussion forward, with a radical new solution; > everything you have said so far are things which have been said over and > over again before. Come up with something which nobody has thought of > before, or take our word for it that everyone who has previously proposed > this has failed. > What do you mean by "take our word for it that everyone who has previously proposed this has failed."? As I mentioned, there are group of people who would like to "remove procedural API completely and make PHP a pure OO language in the future". I understand the motivation very well. It's possible option. However, I don't think we have consensus for "removing procedural API completely and make PHP a pure OO language in the future". The reason why previous proposals have failed is aggressive OO supporter rejected "procedural API improvement", isn't it? Let's see how it goes by vote. This vote is going to be whether we'll take direction to pure OO or multi-paradigm. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
