Hi Rowan, On Wed, Mar 4, 2015 at 6:16 PM, Rowan Collins <rowan.coll...@gmail.com> wrote:
> Several of the costs I listed are for new users, and several will continue > indefinitely if we don't remove the old names, and are therefore long term. > > Could you be more explicit in the benefits you see? I.e. day to day, how > will users lives be better with these new names? > When I start programming with PHP at 2000, I remember that I was confused function naming convention a lot. I hope that current new users do not have such confusions, but they probably feel inconsistent name as issue because it does not look right. Even if IDEs suggest "right" names, I just feel wrong. I guess there are not few people feel same way. People who prefer Ruby likes it because it's not only have shorthand notations but it is predictable in many ways. In PHP7, we finally have uniform(predictable) evaluation order! predictable foreach! why not predictable function names? Since PHP does not have predictable(consistent) names even for most basic functions, function names are not predictable. It makes harder for new PHP developers to get used to. As you mentioned, the changes may cause more confusions in short term. I agree with this. Change causes confusions always more or less... For me, it is a choice whether - we'll have naming confusion forever or - we'll fix it even if there are some confusion in short term resolve it in the long run. >- PHP has API inconsistency even for most basic APIs like phpversion(), > >htmlspecialchars(), etc > > - Even bundled modules have non standard function names. > > - API parameter ordering is inconsistent. > > - Return type for errors are inconsistent. e.g. Wrong number of param > >returns NULL, while others return FALSE mostly. > > For me, argument order and return inconsistency is a much worse problem > than name inconsistency. Unfortunately, it's also harder to fix without > massive BC breaks. Again, this leads to the conclusion of replacing the > entire legacy API, rather than trying to patch over it. > I agree fully. I wish we have FALSE for wrong number of parameters. We should try to provide nicer and consistent new APIs. However, old API will be kept regardless of new APIs because we care compatibility. We still have "is_writeable()" (This is typo function) alias for compatibility, for example. I'll try to modify document system so that it can handle aliases more nicely. e.g. Do not list aliases in function list, but document them in referred function. htmlspecialchars() is documented in html_escape() and make search system find html_escape() by searching "htmlspecialchars". If this is done, we don't have many aliases listed in manual page. I also think having two names for every function will count as a negative > to the kind of people who write these matrixes, and the fact that it was > done to fix a previous negative won't change that. > Keeping legacy names is almost the same as keeping "is_writeable()" for me... I'll try as much as I can, like adjusting manual and search system, so that PHP appears to have consistent function names. This would help people to reconsider. We cannot remove all issue at once. We are better to adopt incremental improvement, aren't we? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
