# [PHP6] Function name consistency - Thread: https://externals.io/message/70896 - Original archive: https://news-web.php.net/php.internals/70896 - Started by Yasuo Ohgaki on 2013-12-28T06:57:34+00:00 - Messages: 43 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/70896.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #70896 — Yasuo Ohgaki — 2013-12-28T06:57:34+00:00 URL: https://externals.io/message/70896#70896 Hi all, I know this has been discussed before, but I'll try again. We have following coding standard 1. Function names for user-level functions should be enclosed with in the PHP_FUNCTION() macro. They should be in lowercase, with words underscore delimited, with care taken to minimize the letter count. Abbreviations should not be used when they greatly decrease the readability of the function name itself:: Good: 'mcrypt_enc_self_test' 'mysql_list_fields' Ok: 'mcrypt_module_get_algo_supported_key_sizes' (could be 'mcrypt_mod_get_algo_sup_key_sizes'?) 'get_html_translation_table' (could be 'html_get_trans_table'?) Bad: 'hw_GetObjectByQueryCollObj' 'pg_setclientencoding' 'jf_n_s_i' https://github.com/php/php-src/blob/master/CODING_STANDARDS There are many functions that violate this for historical reason. Since PHP has function alias feature by default, function names that violate this standard could be renamed and keep historic names as aliases. We may keep alias 10 or 20 years or even forever. Good IDE can suggest correct names, but keeping inconsistent historic function names forever damages PHP future in the long run, IMHO. Any comments? Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #70898 — Hannes Magnusson — 2013-12-28T08:06:09+00:00 URL: https://externals.io/message/70896#70898 · In reply to: #70896 > There are many functions that violate this for historical reason. > Since PHP has function alias feature by default, function names that > violate this standard could be renamed and keep historic names as aliases. > There was a fork at some point (few months (years?) ago) that tried something like that.. Noone cared. I have a local alias list='ls' cause I never remember that command to list the contents of a directory. I tried to fix it upstream, but ... -Hannes --- ## #70899 — Ralf Lang — 2013-12-28T08:43:33+00:00 URL: https://externals.io/message/70896#70899 · In reply to: #70898 > > > > […] > > > There was a fork at some point (few months (years?) ago) that tried > something like that.. Noone cared. > > I have a local alias list='ls' cause I never remember that command to > list the contents of a directory. > I tried to fix it upstream, but ... > > > -Hannes > When redesigning for PHP6, shouldn't most functions move to a class or namespace in the first place? But even if you restrict it to better names, it's a step forward I appreciate. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 --- ## #70949 — Rowan Collins — 2014-01-01T23:26:13+00:00 URL: https://externals.io/message/70896#70949 · In reply to: #70899 > When redesigning for PHP6, shouldn't most functions move to a class or > namespace in the first place? You make it sound like such a redesign is an obvious and achievable goal for the next "major" release of PHP. Neither PHP 5 nor the abandoned PHP 6 branch (Unicode strings, plus the features which were released as 5.3 and 5.4 instead) attempted anything so radical, and the more you change, the harder it is to persuade people to migrate. I suspect this has been discussed a lot of times, although I've only joined the list recently. A search through the archives before taking this discussion further would probably avoid repeating arguments that have been had before, unless anyone has a good summary somewhere? Not that I'm against moving towards consistency per se, but I wouldn't want to assume that whatever stopped it gaining traction in the past no longer applies. Regards, -- Rowan Collins [IMSoP] --- ## #70950 — Rasmus Lerdorf — 2014-01-02T00:07:36+00:00 URL: https://externals.io/message/70896#70950 · In reply to: #70949 > > > […] > > You make it sound like such a redesign is an obvious and achievable goal > for the next "major" release of PHP. Neither PHP 5 nor the abandoned PHP > 6 branch (Unicode strings, plus the features which were released as 5.3 > and 5.4 instead) attempted anything so radical, and the more you change, > the harder it is to persuade people to migrate. > > I suspect this has been discussed a lot of times, although I've only > joined the list recently. A search through the archives before taking > this discussion further would probably avoid repeating arguments that > have been had before, unless anyone has a good summary somewhere? > > Not that I'm against moving towards consistency per se, but I wouldn't > want to assume that whatever stopped it gaining traction in the past no > longer applies. You also need to realize that there is consistency. It is just consistency from a different angle. PHP from day one was always a very thin wrapper on top of dozens, now hundreds, of underlying libraries. The function names and argument order, for the most part, were taken directly from these underlying libraries. So if you were familiar with MySQL's C API, for example, you would instantly be able to navigate PHP's mysql functions to the point where we barely needed PHP MySQL documentation because MySQL's C library documentation covered it function for function. And for many of the str functions (the ones without an underscore), try typing: man strlen/strchr/strrchr/strtok/strpbr/strspn... at your Linux command line prompt. This approach covers the majority of the functions in PHP. The others are somewhat haphazard because it was not always obvious how to name these given there was no underlying API to mimic. So, whenever I see these, "let's just rename everything" posts, I never see the fact that most of these functions are deeply ingrained in the muscle memories of a lot of people addressed. And it is in our muscle memories, not because of PHP, but because we still live in a world written in C. As soon as you venture outside the world of PHP and scripting languages, you hit this world. That doesn't mean we can't try to address this, but simply renaming everything is not the answer. -Rasmus --- ## #70951 — Larry Garfield — 2014-01-02T07:10:07+00:00 URL: https://externals.io/message/70896#70951 · In reply to: #70950 > > > […] > You also need to realize that there is consistency. It is just > consistency from a different angle. PHP from day one was always a very > thin wrapper on top of dozens, now hundreds, of underlying libraries. > The function names and argument order, for the most part, were taken > directly from these underlying libraries. So if you were familiar with > MySQL's C API, for example, you would instantly be able to navigate > PHP's mysql functions to the point where we barely needed PHP MySQL > documentation because MySQL's C library documentation covered it > function for function. And for many of the str functions (the ones > without an underscore), try typing: man > strlen/strchr/strrchr/strtok/strpbr/strspn... at your Linux command line > prompt. > > This approach covers the majority of the functions in PHP. The others > are somewhat haphazard because it was not always obvious how to name > these given there was no underlying API to mimic. > > So, whenever I see these, "let's just rename everything" posts, I never > see the fact that most of these functions are deeply ingrained in the > muscle memories of a lot of people addressed. And it is in our muscle > memories, not because of PHP, but because we still live in a world > written in C. As soon as you venture outside the world of PHP and > scripting languages, you hit this world. > > That doesn't mean we can't try to address this, but simply renaming > everything is not the answer. > > -Rasmus Rasmus, I know you've made this point many times and it is valid historically, but I am not convinced it's valid in the day to day practice of most PHP developers. Only a tiny fraction of the PHP developers I know have any knowledge of C, POSIX, etc., and I think all of them are on this list (or were until recently). While it's great that, for example, ext/mysql is virtually identical to The MySQL C APIs, that is really no consolation for someone who has never looked at (nor needed to, nor had any desire to) the MySQL C bindings. I'm pretty sure most PHP developers' second language isn't C; odds are it's Javascript, and after that either Python or Ruby. (I have no firm data to back that up; it's just my gut feeling based on the developers I interact with across the community.) I agree that "rename all the things" doesn't help, for BC reasons if nothing else; even with huge language improvements in a major version, it still needs to be possible to run well-behaved code across several contiguous versions or adoption will be nil. That means `strlen()`, `strrchr()`, etc. are not going anywhere. What I'd suggest instead, and I am not the first to suggest, is to leave the existing functions in place; let them be happy. Then in PHP.nextMajor (whatever that is), add new well-developed, thought-out, probably OOP, namespaced routines for strings, arrays/collections, etc. Those should be based on trends, standards, and conventions that are not older than half the people on this list. Replacing \strlen() with \string_length() has no real value, I agree. However, (as an example) offering $string->length() "some string"->length() $iterable_including_arrays->map(function($a){})->filter(function($a) {}); now that's worth doing, and worth making big changes for. But that can/should be done without touching any of the existing functions, because we don't want to break BC there for userspace code. If one method happens to internally sub-call to the other in the engine, meh, I don't care and neither does anyone else in userspace. --Larry Garfield --- ## #70952 — Pierre Joye — 2014-01-02T08:07:31+00:00 URL: https://externals.io/message/70896#70952 · In reply to: #70896 > > Hi all, > > I know this has been discussed before, but I'll try again. > We have following coding standard > > 1. Function names for user-level functions should be enclosed with in > the PHP_FUNCTION() macro. They should be in lowercase, with words > underscore delimited, with care taken to minimize the letter count. > Abbreviations should not be used when they greatly decrease the > readability of the function name itself:: There are a couple of solutions to this problem. 1. Change all the existing functions signatures. Bad idea per se as we can forget any fast adoption, if any at all. Will be very painful to migrate existing code 2. Add aliases all around. Not a big fan of that one either. It clutters the php NS a lot without factual gains 3. Try to implement nickic's prototype to add methods to scalar related types, should work with complex types as well I would prefer to give 3. a try, while it could be tricky to implement a technically acceptable solution. Pros: . It will bring consistent APIs . does not add dozen of aliases for little gains . fully BC . fits more to current development habits Cons: . still have to be careful by designing the new "methods" Cheers, Pierre --- ## #70956 — Nils Andre — 2014-01-02T13:59:10+00:00 URL: https://externals.io/message/70896#70956 · In reply to: #70952 Hi Folks, I really like the idea from Larry Garfield or Pierre Joye's proposal (3). We now do have some things cluttered, and it does not matter because of what this is cluttered or if it's only the C world shining through. Programmatically spoken, to me and many OO folks, these things are inconsitently named and the strlen("somesting")... syntax is very 1980s to have. Anyways, any change should not break existing code, but must strive for new code being written to be more maintainable, readable and OOP-like. Either these functions must live in this space forever (and can get proper aliases or mappings to OO-compliant syntax), or, if one tends to disable them, we could have some switch in INI or in a script, enabling all of them back again, like init_set('PHP5_FUNC_COMPAT', true); For old projects that depend on them, the main PHP include would then include this flag and the functions would be made available. Cheers, Nils 2014/1/2 Pierre Joye : > > > […] > > There are a couple of solutions to this problem. > > 1. Change all the existing functions signatures. Bad idea per se as we can > forget any fast adoption, if any at all. Will be very painful to migrate > existing code > > 2. Add aliases all around. > Not a big fan of that one either. It clutters the php NS a lot without > factual gains > > 3. Try to implement nickic's prototype to add methods to scalar related > types, should work with complex types as well > > I would prefer to give 3. a try, while it could be tricky to implement a > technically acceptable solution. > > Pros: > > . It will bring consistent APIs > . does not add dozen of aliases for little gains > . fully BC > . fits more to current development habits > > Cons: > . still have to be careful by designing the new "methods" > > Cheers, > Pierre --- ## #70959 — Robert Parker — 2014-01-02T17:49:21+00:00 URL: https://externals.io/message/70896#70959 · In reply to: #70951 > > > […] > > Rasmus, I know you've made this point many times and it is valid > historically, but I am not convinced it's valid in the day to day > practice of most PHP developers. Only a tiny fraction of the PHP > developers I know have any knowledge of C, POSIX, etc., and I think > all of them are on this list (or were until recently). While it's > great that, for example, ext/mysql is virtually identical to The MySQL > C APIs, that is really no consolation for someone who has never looked > at (nor needed to, nor had any desire to) the MySQL C bindings. > > I'm pretty sure most PHP developers' second language isn't C; odds are > it's Javascript, and after that either Python or Ruby. (I have no > firm data to back that up; it's just my gut feeling based on the > developers I interact with across the community.) > > I agree that "rename all the things" doesn't help, for BC reasons if > nothing else; even with huge language improvements in a major version, > it still needs to be possible to run well-behaved code across several > contiguous versions or adoption will be nil. That means `strlen()`, > `strrchr()`, etc. are not going anywhere. > > What I'd suggest instead, and I am not the first to suggest, is to > leave the existing functions in place; let them be happy. Then in > PHP.nextMajor (whatever that is), add new well-developed, thought-out, > probably OOP, namespaced routines for strings, arrays/collections, > etc. Those should be based on trends, standards, and conventions that > are not older than half the people on this list. > > Replacing \strlen() with \string_length() has no real value, I agree. > However, (as an example) offering > > $string->length() > "some string"->length() > $iterable_including_arrays->map(function($a){})->filter(function($a) > {}); > > now that's worth doing, and worth making big changes for. But that > can/should be done without touching any of the existing functions, > because we don't want to break BC there for userspace code. If one > method happens to internally sub-call to the other in the engine, meh, > I don't care and neither does anyone else in userspace. > > --Larry Garfield I would consider myself one of those php developers. I know very little c, and java. Javascript is my second language after php. Most php developers have yet to move towards 5.3 and don't know how to even use namespaces or what they are. They often use wordpress or drupal which are very slow to adapt. Considering how slow and hard it is for most php developers to migrate to new versions of php I do not think creating aliases or changing the names would be beneficial. Different developers would use different aliases and it would confuse a lot of php developers. IMO the best solution is to have more SPL objects in php 6. People can either use the old functional php or the new OO php and the OO would have more consistent names. --Robert Parker --- ## #70965 — Tim Rhodes — 2014-01-02T19:40:31+00:00 URL: https://externals.io/message/70896#70965 · In reply to: #70959 I've done PHP, C, Javascript, and C# for 15 years now. I greatly prefer PHP. Putting types, classes and functions behind a namespace seems the most usable. Usually documentation is easier to understand since the related information is always behind a namespace. Also using Pierre's "init_set('PHP5_FUNC_COMPAT', true);" to define the current functions (although the default should be true) would allow older code to work without changes. Moving to namespaces would allow better consistent naming. Although this point can be moot because of IDEs, however it does force a developer to know what classes and functions are going to be running in their application. Moving strictly to an OO language would remove some of the easy for beginners to start and easy to prototype features of the language. Timothy Rhodes > > > > […] > > I would consider myself one of those php developers. I know very little c, > and java. Javascript is my second language after php. Most php developers > have yet to move towards 5.3 and don't know how to even use namespaces or > what they are. They often use wordpress or drupal which are very slow to > adapt. > > Considering how slow and hard it is for most php developers to migrate to > new versions of php I do not think creating aliases or changing the names > would be beneficial. Different developers would use different aliases and > it would confuse a lot of php developers. > > IMO the best solution is to have more SPL objects in php 6. People can > either use the old functional php or the new OO php and the OO would have > more consistent names. > > --Robert Parker --- ## #70966 — Yasuo Ohgaki — 2014-01-02T19:42:12+00:00 URL: https://externals.io/message/70896#70966 · In reply to: #70959 HI all, > I would consider myself one of those php developers. I know very little c, > and java. Javascript is my second language after php. Most php developers > have yet to move towards 5.3 and don't know how to even use namespaces or > what they are. They often use wordpress or drupal which are very slow to > adapt. > > Considering how slow and hard it is for most php developers to migrate to > new versions of php I do not think creating aliases or changing the names > would be beneficial. Different developers would use different aliases and > it would confuse a lot of php developers. > This proposal does not intend to force users to adopt new names, but ensure PHP popularity in the long run. Are new users willing to learn language that have full of inconsistent names even for basic/standard/default functions? My intention to have consistent function names for old function is - to ensure PHP as attractive language to learn even 10 or 20 years later. I agree that adoption of new feature is slow. If we made function names consistent now, there would be codes around uses historic names 10 years later, but it does not matter for the purpose of this proposal. De facto Standard names such as `strchr()` would be acceptable names even 20 years from now. Other functions such as GD functions are better to have consistent names. Please consider this proposal is for new users that will learn PHP from now or in the future. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #70968 — Florin Patan — 2014-01-02T20:00:29+00:00 URL: https://externals.io/message/70896#70968 · In reply to: #70966 > > HI all, > > > > > […] > > This proposal does not intend to force users to adopt new names, but ensure > PHP popularity in the long run. > > Are new users willing to learn language that have full of inconsistent > names > even for basic/standard/default functions? > > My intention to have consistent function names for old function is > > - to ensure PHP as attractive language to learn even 10 or 20 years later. > > I agree that adoption of new feature is slow. If we made function names > consistent now, there would be codes around uses historic names 10 years > later, but it does not matter for the purpose of this proposal. > > De facto Standard names such as `strchr()` would be acceptable names even > 20 years from now. Other functions such as GD functions are better to have > consistent names. > > Please consider this proposal is for new users that will learn PHP from now > or > in the future. > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net If you look at golang you'll see they have 'go fix' http://golang.org/cmd/fix/ which helps mitigate the effects of language changes automatically. I suppose it wouldn't be a problem with having a tool that can generate an AST out of a .php file and dump it back to a newer syntax (as long as only the function / method / classes name and parameter order is changing). The issue I see is that people are stuck into the: 'bbbut it's using the underlying uber-duper library and if a dozen people know about it then it must be a good thing' approach. Also, having a flag in the engine, with some ini_set(blah, true) seems like a poor decision imo. Fix the problem at the source, don't clutter the engine because the php users are too lazy to run an automated tool. And yes, I do suggest that PHP should start to impose a certain formatting, since it would be needed by this tool, but if you look past the initial: ':(((( I want my tabs / spaces back' or whatever, in a couple of days / weeks everyone would forget about the formatting issues and just focus on the code. @Yasuo, if you really want to keep PHP attractive maybe you should look on what golang is doing because imo they served every other languages a lesson in tooling and not only. ---- Florin Patan / @dlsniper https://github.com/dlsniper http://www.linkedin.com/in/florinpatan --- ## #70969 — Yasuo Ohgaki — 2014-01-02T20:11:44+00:00 URL: https://externals.io/message/70896#70969 · In reply to: #70968 Hi Florin, > @Yasuo, if you really want to keep PHP attractive maybe you should > look on what golang is doing because imo they served every other > languages a lesson in tooling and not only. > Thanks. I'm not familiar with Go yet, but I have an idea for DbC (design by contract) for PHP. Anyway, I'll learn it soon :) -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #70970 — Florin Patan — 2014-01-02T20:14:02+00:00 URL: https://externals.io/message/70896#70970 · In reply to: #70969 > > Hi Florin, > > > > […] > > > Thanks. > I'm not familiar with Go yet, but I have an idea for DbC (design by > contract) for PHP. > Anyway, I'll learn it soon :) > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net Also Pythons' 2to3 might be interesting to check out: http://docs.python.org/2/library/2to3.html Cheers. ---- Florin Patan / @dlsniper https://github.com/dlsniper http://www.linkedin.com/in/florinpatan --- ## #70973 — Robert Parker — 2014-01-02T22:43:37+00:00 URL: https://externals.io/message/70896#70973 · In reply to: #70965 > I've done PHP, C, Javascript, and C# for 15 years now. I greatly prefer > PHP. Putting types, classes and functions behind a namespace seems the > most usable. Usually documentation is easier to understand since the > related information is always behind a namespace. Also using Pierre's > "init_set('PHP5_FUNC_COMPAT', > true);" to define the current functions (although the default should be > true) would allow older code to work without changes. Moving to > namespaces > would allow better consistent naming. Although this point can be moot > because of IDEs, however it does force a developer to know what classes > and > functions are going to be running in their application. > > Moving strictly to an OO language would remove some of the easy for > beginners to start and easy to prototype features of the language. > > > Timothy Rhodes > > > On Thu, Jan 2, 2014 at 11:49 AM, Robert Parker > wrote: > > > […] I was not implying an OO only language. I love how php is not strictly OO. The point I was trying to get across is that most php developers will not adapt until unless they absolutely have too. Changing functions would be a huge deal to these people. using a tool is probably out of the question for them unless it was a gui based tool. Allowing different names would be confusing to them also. IDEs wouln't help IMO because they don't use them. I have been using PHP for about 5 years and just started my career as a web developer. TBH I have only once meet someone who uses version control and knows what namespaces are. only a few people used an IDE or knew what an IDE was. I know there's a lot of great php developers out there but I do not think the make up the majority. Maybe it's demographics. I live in OR USA. I think we should leave the functions as they are and include more SPL objects. The SPL would be more consistent for the people who do OOP. --- ## #70974 — Florin Patan — 2014-01-02T23:26:36+00:00 URL: https://externals.io/message/70896#70974 · In reply to: #70973 > > > > […] > > I was not implying an OO only language. I love how php is not strictly OO. > The point I was trying to get across is that most php developers will not > adapt until unless they absolutely have too. Changing functions would be a > huge deal to these people. using a tool is probably out of the question for > them unless it was a gui based tool. Allowing different names would be > confusing to them also. IDEs wouln't help IMO because they don't use them. > > I have been using PHP for about 5 years and just started my career as a web > developer. TBH I have only once meet someone who uses version control and > knows what namespaces are. only a few people used an IDE or knew what an IDE > was. I know there's a lot of great php developers out there but I do not > think the make up the majority. Maybe it's demographics. I live in OR USA. > > I think we should leave the functions as they are and include more SPL > objects. The SPL would be more consistent for the people who do OOP. > > > -- > > > (This not PHP specific nor it's targeted any specific person or group) So, the argument of having a bad language is that if the people who use it are bad then it should stay bad forever? Shouldn't a language strive to be better and better, promote good practices and enhance the way people program not just write code? And if it's that hard to run "php -5to6 /path/to/file.php" then I guess one needs to wonder if he's really in the right business. Yes, you may have a tool that is using some fancy interface, but CLI itself is also a GUI on it's own. Maybe making the whole thing consistent is coming a bit too late now in the game, at least for old stuff and considering the spread of PHP there's going to be lots of people frustrated about changes. Something like this shouldn't be treated lightly nor should it be done without a form of automated migration (again, engine support is not that solution). But on the other hand, sticking to a solution because it's yours or because you got accustomed to it it's not something a programmer should do either. As for PHP6 to come to life and be adopted, besides a single 'oh look, PHP6 is here with all the functions renamed / parameter shifted around' it has to come with more then that, HHVM integration is a good start, seeing how it's holding pretty well in benchmarks and finally it's being considered as something that might be looked into in the future, something that a year ago was a: 'oh no, no'. Regards, Florin ---- Florin Patan / @dlsniper https://github.com/dlsniper http://www.linkedin.com/in/florinpatan --- ## #70976 — Rowan Collins — 2014-01-03T02:14:57+00:00 URL: https://externals.io/message/70896#70976 · In reply to: #70968 > I suppose it wouldn't be a problem with having a tool that can > generate an AST out of a .php file and dump it back to a newer syntax > (as long as only the function / method / classes name and parameter > order is changing). Don't forget that there are various ways to do what could loosely be described as "reflection" or "meta-programming" in PHP - e.g. given call_user_func_array($func, $args) we may need to correct the name stored in the string $func, or the order of items in the array $args. These are very hard to even detect with an automated tool, let alone fix - indeed, I doubt it is even theoretically possible in many cases. That leaves you with either code that needs painstaking manual upgrades, or a runtime compatibility mode. Both of these come with a cost to the community at large - many people want to distribute (or internally manage) code that is both backwards and forwards compatible, i.e. runs on as many past and future versions of the platform as possible. That's impossible to do with a hard compatibility break, and tricky if the compatibility breaks are subtle (such as new function names/aliases) as you have to keep testing and removing the new names until you no longer need to support the old versions. A more fundamental restructuring (e.g. an OO implementation of "basic" operations) could more happily sit alongside the existing functionality, with code very obviously using either one style or the other, and compatibility easy to maintain over the longer term. Regards, -- Rowan Collins [IMSoP] --- ## #70977 — Rasmus Lerdorf — 2014-01-03T02:15:45+00:00 URL: https://externals.io/message/70896#70977 · In reply to: #70974 > As for PHP6 to come to life and be adopted, besides a single 'oh look, > PHP6 is here with all the functions renamed / parameter shifted > around' it has to come with more then that, HHVM integration is a good > start, seeing how it's holding pretty well in benchmarks and finally > it's being considered as something that might be looked into in the > future, something that a year ago was a: 'oh no, no'. Because it was a completely different thing then which FB also realized and completely changed gears to be more in line with PHP. Now that they have done that it is much more interesting to us. If they hadn't, it would still be an 'oh no, no' as you so eloquently and mockingly put it. -Rasmus --- ## #71416 — Yasuo Ohgaki — 2014-01-22T22:17:25+00:00 URL: https://externals.io/message/70896#71416 · In reply to: #70896 > I know this has been discussed before, but I'll try again. > We have following coding standard > > 1. Function names for user-level functions should be enclosed with in > the PHP_FUNCTION() macro. They should be in lowercase, with words > underscore delimited, with care taken to minimize the letter count. > Abbreviations should not be used when they greatly decrease the > readability of the function name itself:: > > Good: > 'mcrypt_enc_self_test' > 'mysql_list_fields' > > Ok: > 'mcrypt_module_get_algo_supported_key_sizes' > (could be 'mcrypt_mod_get_algo_sup_key_sizes'?) > 'get_html_translation_table' > (could be 'html_get_trans_table'?) > > Bad: > 'hw_GetObjectByQueryCollObj' > 'pg_setclientencoding' > 'jf_n_s_i' > > https://github.com/php/php-src/blob/master/CODING_STANDARDS > > > There are many functions that violate this for historical reason. > Since PHP has function alias feature by default, function names that > violate this standard could be renamed and keep historic names as aliases. > > We may keep alias 10 or 20 years or even forever. > > Good IDE can suggest correct names, but keeping inconsistent historic > function names forever damages PHP future in the long run, IMHO. > > Any comments? > Added RFC for this. https://wiki.php.net/rfc/consistent-names Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #71417 — Andrea Faulds — 2014-01-22T22:20:28+00:00 URL: https://externals.io/message/70896#71417 · In reply to: #71416 > Added RFC for this. > > https://wiki.php.net/rfc/consistent-names You seem pretty eager to make RFCs ;) You should probably announce it to the list directly as well. -- Andrea Faulds http://ajf.me/ --- ## #71418 — Yasuo Ohgaki — 2014-01-22T22:33:08+00:00 URL: https://externals.io/message/70896#71418 · In reply to: #71417 Hi Andrea, > > > > […] > > You seem pretty eager to make RFCs ;) > > You should probably announce it to the list directly as well. I just don't want to forget about it :) I made it as reminder. Since we are 5.6 release phase, it might be better bring up this after 5.6 release. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #71449 — Chris Wright — 2014-01-23T17:45:34+00:00 URL: https://externals.io/message/70896#71449 > Maybe it's a stupid idea, you'll tell me :) Wouldn't it be a good thing to > issue a notice when people use the alias instead of the correct function > name? > This is essentially a description of the visible effects of deprecation, and would cause a *lot* of issues in userland if this was done straight away, since there are literally millions of applications using functions that are candidates to be aliased in every page load - remember that everything, including error messages, has an overhead. As Yasuo stated in the first message in the thread: > We may keep alias 10 or 20 years or even forever. We can't consider deprecating (or even "soft deprecating" in the manual, as happened with ext/mysql) any of the old names for a long, long time, as many of them are far to deeply burned into the PHP ecosystem. Thanks, Chris --- ## #71469 — Larry Garfield — 2014-01-24T01:11:12+00:00 URL: https://externals.io/message/70896#71469 > Therein lies the whole problem with adding more aliases - it just makes > things more inconsistent, as developers can use (deliberately or > accidentally) different names for the same function. > > I still have to think a moment when I see `sizeof()` or print, rather than > `count()` or echo - let alone having to remember which version of PHP > introduced which alias so that libraries don't break when deployed to > older servers. > > I think it's far better to have replacements for whole sets of functions > that are clearly "new and shiny" - be that OO strings and arrays, or > just namespaces for extensions like mbstring. In fact, a namespace for > mbstring could allow a much cleaner version of the "override normal > string functions" system, because you could just "use" the namespace, > and have functions with overlapping names... > > Regards, > Rowan Collins > [IMSoP] Agreed. Simply aliasing a bunch of functions offers no useful value, but does increase confusion. ("Wait, do I use `strcmp()` or string_compare() on this project? What version are we on again? Oh, look, this library uses both. Must have been different devs. FML.") If we're going to do anything, be aggressive and far-reaching with it. Build a proper language-level OOP design for string/array manipulation. We have enough functions lying about. Don't add more. --Larry Garfield --- ## #71526 — Yasuo Ohgaki — 2014-01-24T20:27:02+00:00 URL: https://externals.io/message/70896#71526 · In reply to: #71469 Hi Larry, On Fri, Jan 24, 2014 at 10:11 AM, Larry Garfield wrote: > > > Therein lies the whole problem with adding more aliases - it just makes > > […] > > Agreed. Simply aliasing a bunch of functions offers no useful value, but > does increase confusion. ("Wait, do I use `strcmp()` or string_compare() on > this project? What version are we on again? Oh, look, this library uses > both. Must have been different devs. FML.") > > If we're going to do anything, be aggressive and far-reaching with it. > Build a proper language-level OOP design for string/array manipulation. > > We have enough functions lying about. Don't add more. We should be careful choosing names. I agree. However, not adding more function names is simply impossible. For example, I'm about to add new session function named string session_create_id([string $prefix]) for user save handlers, so that user could generate secure ID easily. It's a straight name for session ID creation and there might be users using this name. Not adding any new names means not adding any new features nor cleanups. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #71528 — Larry Garfield — 2014-01-24T20:38:07+00:00 URL: https://externals.io/message/70896#71528 · In reply to: #71526 > > […] > > > We should be careful choosing names. I agree. > However, not adding more function names is simply impossible. > For example, I'm about to add new session function named > > string session_create_id([string $prefix]) > > for user save handlers, so that user could generate secure ID > easily. It's a straight name for session ID creation and there > might be users using this name. > > Not adding any new names means not adding any new features > nor cleanups. > > Regards, I don't mean "never add a function again". I mean adding functions for no particular value other than having more of them helps nothing, and arguably makes the situation worse. Where possible, we shouldn't be adding yet-another-utility-function but looking to how to build more complete and functional language capabilities and standard libraries, rather than piecemeal addition of functions one RFC at a time. For your example, for instance, session handling is as of PHP 5.4 an object. That's the cleaner way to handle it than a bunch of functions. Can that function be better integrated into an API rather than just added to a long list of tools? I don't know; maybe. But we should be asking those questions, not saying "how many more ways to type `strcmp()` can we introduce to confuse people." --Larry Garfield --- Next page: https://externals.io/message/70896.md?page=2