Hi Rowan, On Fri, Mar 6, 2015 at 8:50 AM, Rowan Collins <rowan.coll...@gmail.com> wrote:
> On 5 March 2015 22:05:05 GMT, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > >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. > > > That's actually the advantage of an OO-style API - it's really obvious > which set of functions someone else is using, and really easy to look at > the two side by side. > > Users will not spend their time cross-referencing every function they see > in a tutorial against the manual to see if it's been renamed with some > extra underscores, and whether the new name has a different parameter order > or error behaviour. But they might well read an article on how in version > X, you can write things with this different syntax, and they'd instantly > see that the old tutorial they found wasn't using that syntax. > We have ArrayObject. http://php.net/manual/en/class.arrayobject.php I'm not a supporter of this class. Both class name and methods are not good enough. Implementation seems complex overly. It sounds like you are going to oppose to have improved array classes and/or array variable OO extension for the same reason. - Do you oppose to have better array class alternatives because of ArrayObject? - Do you think we must stick to this class/methods because it's already been here for a long time? - Do you oppose to have array variable object, i.e. $var_array->sort(), because we have ArrayObject already? - Do you agree if I object to have new/better OO API by existence of ArrayObject? > > > >>> 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" > > > Again, you bring it back to the assumption that "new API" means "not > procedural any more". I'm not sure how many different ways I can find of > saying that's not the point. > I thought you prefer to have scalar object (including array) rather than procedural API fix/improvement. I'm lost here. So how would you like to fix naming mess and parameter miss ordering issue in procedural APIs? Leave inconsistent procedural functions forever? > > >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. > > > Please don't credit me with that suggestion. It comes up just as often as > the naming consistency, with just as much lack of support. Hence the bullet > on the "mysterious PHP RFC process" blog post requesting that nobody try to > put forward an RFC for either of them. > > > > >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. > > > It's not that it doesn't do enough to keep the API around - frankly, I > can't see those functions going away whatever happens. It's that it doesn't > do enough for people to want to start using the new functions. Who is going > to bother replacing all their instances of in_array with array_in? > I agree that old functions should be able to use. Old name aliases should stay forever. Users do not have to rewrite their code with this RFC. They can use old names as long as they wish. Old codes are not invalid code, but perfectly valid code. So your idea is to leaving behind procedural API inconsistencies forever and keep as it is? > > > >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 used to really like the idea of a namespace with all the new functions > in, and indeed the bulk import/default namespace idea, but I realised it > doesn't really help. You have zero BC, but you also have a language which > is incredibly hard to read, because the same line of code will do different > things based on whether the file begins with a particular "use" statement. > And now, rather than being confused about whether array_key_exists takes > needle first or second, users have to be confused that it sometimes works > one way, and sometimes the other, depending on which namespace they're > operating in. > I agree. Flexibility comes with its cost. It's possible to write incredibly hard to read code with Ruby/JavaScript/Scheme/etc. This is one of the reason why I didn't propose "namespace" use. Keeping RFC simple is better to discuss targeted issue. Even without such feature, we may do PHP FizzBuzz http://3v4l.org/KFRj6 <? $_ = ("@]@@]@"^"#/%!)%")._.("@]@@]@@@"^"&(.#))/."); $__=$_('$__,$____',' $_ = !""; $$_ = +""; $___ = $_ + $_ + $_; $_____ = $___+$_+$_; $$$_ ="|@@@"^":)::"; $$$$_ = "|]@@"^">(::"; $$___ = "]]).]:"^"-/@@)\\\"; $$___(($__%($_ . $_____)?$__%$_____?$__%$___?$__:$$$_:$$$$_:$$$_.$$$$_)." "); $__- ($_ . $$_ . $$_) && $____($__+!"",$____); '); $__(!'',$__); Ruby FizzBuzz $____="#"=~/$/;$___=$____+$____;$_=$____+$___;$__=$___+$_;$_____=$___+ $__;@@_=""<<($_*$_*$_____+$_); @@__=""<<($___*$__*$_____);@__=""<<($_* $__*$_____); @___=""<<($__**$_-$___**$_);@_=""<<($__**$_-$_);@_<<@_;__= ->(_){_>$____&&__.(_-$____);($><<[_%$_<$____?(@@__+@__+@_):_%$__>(""=~ //)?_:'',[@@_+@___+@_][_%$__]]*''+(""<<($___*$__)))};__.($___*$___*$__*$__) JavaScript FizzBuzz $=+[];$={___:$++,__$:$++,_$_:$++,_$$:$++,$__:$++,$_$:$++,$$_:$++,$$$:$++};_=($. ___)[({}+"")[$.$_$]+({}+"")[$.__$]+({}.$+"")[$.__$]+(!{}+"")[$._$$]+(!!{}+"")[$ .___]+(!!{}+"")[$.__$]+({}.$+"")[$.___]+({}+"")[$.$_$]+(!!{}+"")[$.___]+({}+"") [$.__$]+(!!{}+"")[$.__$]][({}+"")[$.$_$]+({}+"")[$.__$]+({}.$+"")[$.__$]+(!{}+ "")[$._$$]+(!!{}+"")[$.___]+(!!{}+"")[$.__$]+({}.$+"")[$.___]+({}+"")[$.$_$]+(! !{}+"")[$.___]+({}+"")[$.__$]+(!!{}+"")[$.__$]]((!!{}+"")[$.__$]+(!!{}+"")[$._$$ ]+(!!{}+"")[$.___]+(!!{}+"")[$._$_]+(!!{}+"")[$.__$]+({}.$+"")[$.__$]+"\""+"\\" +$.__$+$.$$_+$._$$+"\\"+$.$$$+$.$_$+"\\"+$.$__+$.$$$+"\\"+$.$__+$.$$$+"\\"+$.$$$ +$._$$+"\\"+$.__$+$.$__+$.$$_+"\\"+$.__$+$.$_$+$.$$$+"\\"+$.__$+$.$$_+$._$_+"\\" +$.$_$+$.___+"\\"+$.__$+$.$_$+$.__$+"\\"+$.$$$+$.$_$+"\\"+$.$$_+$.__$+"\\"+$.$$$ +$._$$+"\\"+$.__$+$.$_$+$.__$+"\\"+$.$$$+$.$__+"\\"+$.$$$+$.$_$+"\\"+$.$$_+$.__$ +"\\"+$.$$_+$.___+"\\"+$.$$_+$.___+"\\"+$.$$$+$._$$+"\\"+$.$_$+$._$$+"\\"+$.$_$+ $._$$+"\\"+$.__$+$.$_$+$.__$+"\\"+$.$_$+$.__$+"\\"+$.__$+$.$$$+$._$$+"\\"+$.__$+ $.$$_+$._$$+"\\"+$.$_$+$._$$+"\\"+$.$$$+$.$_$+"\\"+$.$_$+$.___+"\\"+$.__$+$.$_$+ $.__$+"\\"+$.$__+$.$_$+"\\"+$.$$_+$.__$+"\\"+$.$$_+$.$_$+"\\"+$.$$$+$.$_$+"\\"+$ .$$$+$.$_$+"\\"+$.$$_+$.___+"\\"+$.$$$+$.$$$+"\\"+$.$__+$.$$$+"\\"+$.__$+$.___+$ .$$_+"\\"+$.__$+$.$_$+$.__$+"\\"+$.__$+$.$$$+$._$_+"\\"+$.__$+$.$$$+$._$_+"\\"+$ .__$+$.___+$._$_+"\\"+$.__$+$.$$_+$.$_$+"\\"+$.__$+$.$$$+$._$_+"\\"+$.__$+$.$$$+ $._$_+"\\"+$.$__+$.$$$+"\\"+$.$$$+$._$_+"\\"+$.__$+$.$_$+$.__$+"\\"+$.$__+$.$_$+ "\\"+$.$$_+$._$$+"\\"+$.$$$+$.$_$+"\\"+$.$$$+$.$_$+"\\"+$.$$_+$.___+"\\"+$.$$$+$ .$$$+"\\"+$.$__+$.$$$+"\\"+$.__$+$.___+$.$$_+"\\"+$.__$+$.$_$+$.__$+"\\"+$.__$+$ .$$$+$._$_+"\\"+$.__$+$.$$$+$._$_+"\\"+$.$__+$.$$$+"\\"+$.$$$+$._$_+"\\"+$.__$+$ .$_$+$.__$+"\\"+$.$__+$.$_$+"\\"+$.$$_+$.$_$+"\\"+$.$$$+$.$_$+"\\"+$.$$$+$.$_$+ "\\"+$.$$_+$.___+"\\"+$.$$$+$.$$$+"\\"+$.$__+$.$$$+"\\"+$.__$+$.___+$._$_+"\\"+$ .__$+$.$$_+$.$_$+"\\"+$.__$+$.$$$+$._$_+"\\"+$.__$+$.$$$+$._$_+"\\"+$.$__+$.$$$+ "\\"+$.$$$+$._$_+"\\"+$.__$+$.$_$+$.__$+"\\"+$.$_$+$.__$+"\\"+$.$_$+$._$$+"\\"+$ .$__+$.$$$+"\\"+$.__$+$._$$+$.$__+"\\"+$.__$+$.$_$+$.$$_+"\\"+$.$__+$.$$$+"\\"+$ .__$+$.$$$+$.$_$+"\\"+$.__$+$.$__+$.$$_+"\\"+$.$$$+$.$_$+"\\"+$.$_$+$.___+"\\"+$ .__$+$.$$_+$.$__+"\\"+$.__$+$.$$$+$.__$+"\\"+$.__$+$.$$_+$.___+"\\"+$.__$+$.$__+ $.$_$+"\\"+$.__$+$.$_$+$.$$$+"\\"+$.__$+$.$__+$.$$_+"\\"+$.$__+$.___+"\\"+$.__$+ $.$__+$.__$+"\\"+$.__$+$.$_$+$.$__+"\\"+$.__$+$.$__+$.$_$+"\\"+$.__$+$.$$_+$._$_ +"\\"+$.__$+$.$$_+$.$__+"\\"+$.$$$+$.$_$+"\\"+$.$$$+$.$_$+"\\"+$.$__+$.$$$+"\\"+ $.__$+$.$__+$.$$_+"\\"+$.__$+$.$$_+$.$_$+"\\"+$.__$+$.$_$+$.$$_+"\\"+$.__$+$.$__ +$._$$+"\\"+$.__$+$.$$_+$.$__+"\\"+$.__$+$.$_$+$.__$+"\\"+$.__$+$.$_$+$.$$$+"\\" +$.__$+$.$_$+$.$$_+"\\"+$.$__+$.$$$+"\\"+$.$_$+$.__$+"\\"+$.$$$+$.$$$+"\\"+$.__$ +$.$__+$.__$+"\\"+$.__$+$.$_$+$.$__+"\\"+$.__$+$.$__+$.$_$+"\\"+$.__$+$.$$_+$. _$_+"\\"+$.__$+$.$$_+$.$__+"\\"+$.$$$+$._$_+"\\"+$.__$+$.$$_+$.___+"\\"+$.__$+$ .$$_+$._$_+"\\"+$.__$+$.$_$+$.__$+"\\"+$.__$+$.$_$+$.$$_+"\\"+$.__$+$.$$_+$.$__ +"\\"+$.$$$+$._$$+"\\"+$.__$+$.$__+$.$$_+"\\"+$.$_$+$.___+"\\"+$.__$+$.$$_+$._$$ +"\\"+$.$_$+$.__$+"\"");($.___)[({}+"")[$.$_$]+({}+"")[$.__$]+({}.$+"")[$.__$]+( !{}+"")[$._$$]+(!!{}+"")[$.___]+(!!{}+"")[$.__$]+({}.$+"")[$.___]+({}+"")[$.$_$] +(!!{}+"")[$.___]+({}+"")[$.__$]+(!!{}+"")[$.__$]][({}+"")[$.$_$]+({}+"")[$.__$] +({}.$+"")[$.__$]+(!{}+"")[$._$$]+(!!{}+"")[$.___]+(!!{}+"")[$.__$]+({}.$+"")[$. ___]+({}+"")[$.$_$]+(!!{}+"")[$.___]+({}+"")[$.__$]+(!!{}+"")[$.__$]](_())() > > > >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."? > > > I mean that you are approaching this with the enthusiasm of someone > bringing a new idea to the table, and trying to win over people who've been > working on the prioject for years. But the fact is that this conversation > has been had before, many times over, and it has never been adopted before. > You have very little chance of getting it adopted this time. > You are probably right. There were roughly 4 groups of people. 1. Inconsistent/legacy procedural API must be replaced by new/better OO API 2. Do not care consistency and keep it as it is now. 3. Some current names are good enough and should not be removed. (e.g. IEEE/C lib based names) 4. Consistent naming is important. 1, 2 and 3 are majority. I added IEEE/lib names as a part of PHP standard names. There will be more supporters hopefully, but it seems it's not enough. > > > >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". > > > There may be such people, yes. But they are not your main problem in > getting your proposal adopted. Your main problem are two groups: > - those who think it is far too late to change any of this, and that it's > just not worth the hassle for a few minor annoyances > - those who think that it might be justifiable if we can find a way of > making a compelling new set of functions, rather than just tweaking a few > corner cases > Thank you for the analysis. It's reasonable one. I should think how to persuade them. Changes are never too late! Especially non destructive change like this RFC. Why one, who is using old names already, should care for new names? Old names are valid names still and stay forever. Codes or 3rd party manuals do not have to be updated only for this RFC. It's users/writers option whether to use new names or not. In case of rewrite, simple rewrite is good enough unlike new OO API, except a few functions that have different parameter order. >The reason why previous proposals have failed is aggressive OO > >supporter > >rejected "procedural API improvement", isn't it? > > > No. That is a relatively recent phenomenon, if it's real at all. The > reason previous proposals have failed is that people think the costs > outweigh the benefits. > I saw many "There should be better OO API for them and use them" for PHP5 discussion also. I don't understand the reasoning "costs outweigh the benefits". It sounds like excuse for promoting OO API for me. Use of new OO API requires new codes/manuals. It's more than aliasing. Cost of having new name disappears over time while cost of having inconsistent names accumulate. >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. > > > No, the only vote we can have right now is on the option on the table, so > will be whether it's worth the pain to change things which have worked this > way for twenty years. There is no proposal on the table for making PHP an > OO only language, and I'm not even sure what such a proposal would look > like at this point in time. > > PHP is not in imminent danger of death if we leave a handful of string and > array functions with slightly awkward names and behaviour, so it's not like > we've got to choose between two rescue plans, messing with the functions or > jumping into OO. > > I get that you find those functions annoying, but not everyone agrees with > you. Maybe I'm wrong and there's a silent majority willing to push this > through, but I would be extremely surprised if a vote on this was anything > other than a landslide "no thanks". Again. This RFC is not a destructive RFC at all. Good changes are never too late. Almost all languages does this kind of maintenance/improvement, even destructive changes like dropping old syntax/etc. Unless one is not willing to replace/eliminate legacy and messy procedural API, I don't understand the reasoning to object to have consistent names. It's new consistent names that can be used optionally. Old names are available probably forever. I do rename for my codes to keep it consistent all the time. We do rename PHP internal code to keep it nice and consistent on occasions. I fail to see why not PHP functions, why not giving users a chance to use nice and consistent names if users would like to. Anyway, your opinions to summarize: - User should use new/better OO API. (And we should focus new OO API development) - Inconsistent names should be kept forever. - This RFC requires existing manual/code rewrites. Therefore, this RFC does not worth to adopt. Is this correct? I find a little contradictory opinions here... We need completely new manuals/codes for new OO API while this RFC does not. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
