PHP’s function naming and argument order
Geplaatst in PHP, Webdevelopment Reeds 3 reacties op dit berichtJust got back from PHPVikinger, a unconference, traveling around the world, organised by Derick Rethans. This year’s conference was held in Leuven, and since that is only a 30 minute drive from where I live I had to attend ofcourse.
For the summary of the event itself I’m happy to point you to Jeroen’s blog but I’d like to talk about something Stefan Koopmanschap brought up during Scott’s and Derick’s session on the PDM.
During the Q&A Stefan asked why the developers of PHP didn’t grab the opportunity to clean up the seemingly random and sometimes messed up functionnaming and argument ordering in some of PHP’s internal functions. Stefan by far isn’t the first one to bring this issue up, there are dozens of people reporting and asking this on the mailinglist and even filing bugs for it (with questionable degrees of success) but he did make a very valid point by stating that the release of PHP6 is the moment of choice to introduce these kind of changes in the core functionality of the language.
Function Naming
So what is this all about? Well really, as much as I love PHP, in several area’s it’s a mess. Especially in function naming.
Take the isset() function for example. Why is the is_null() function written with an underscore, these functions seem to me like they belong together since they both inspect a variable and return true or false if the state of the variable is as the function requested. Well then why is is_null written with an underscore and isset not? Doesn’t really make sense unless you want to confuse people.
Another example is the htmlentities() function, this function encodes some characters in a string with their entity value, the function that does the exact opposite is called html_entity_decode(). Again one is written with underscores, the other without. And again without an obvious reason.
Other examples are all the string functions, there are a dozen function that start with str_ and alot more of them that just start with str.
Argument order
Another issue is argument order. There are several functions that seem rather random in the way they order arguments. Especially function that required needle/haystack arguments.
String functions, like strstr() for example, accept $haystack as a first argument and $needle as a second while array function like array_search accept them in the reverse order. It just seems counter intuitive to me.
PHP 6
What disturbs me the most was the reply Scott and Derick gave Stefan at the conference, their reply simply was that it won’t be fixed because otherwise a lot of developers would be upset about the changes and lacking backwards compatibility.
Well they have a valid point there … if you’d consider fixing it in a minor version upgrade like from PHP 5.2 to 5.3. But if we are talking upgrading from PHP 5 to PHP 6 I’m absolutely sure the majority of PHP developers wouldn’t mind giving up backwards compatibility in exchange for fixing these issues. Over time the amount of functions in PHP really isn’t going to decrease so I’d prefer to have it fixed before it really runs out of control. But who am I?
I hope that with this blogpost I’ve inspired some people to think about this subject too and maybe undertake some action and write about it on their blog or twitter it since this isn’t something that is going to change unless us, PHP users, are asking for it and making the PHP core developers aware of these issues and that fixing them is important to us.
I think you’re slightly misrepresenting Scott & Derick’s argument as far as argument order is concerned. They quite convincingly argued that it would break PHP5 code almost beyond repair, since in most cases there’s no way of telling if the arguments have already been switched.
If you see strstr($foo, $bar), there’s no way to know if this was pre-PHP6 code that needs to be ported, or code written for or ported to PHP6. Unfortunately, not all variables in the real world are called $needle and $haystack… This will not just “upset” developers, it would become a large scale nightmare.
Personally, they’ve convinced me why this at least is a very, very bad idea. I still believe we should get rid of these awful inconsistencies, and an alternative would be to deprecate the existing functions and introducing new ones. Even if “deprecated” means the old functions will be with us until PHP8, at least we could choose to ignore them.
@Rick – indeed fixing the functions themself might be a bad idea but the problems should be fixed, and I feel like now is the time. Wether a new set of functions get introduced or the old get altered to reflect the ‘right’ argument order is something that needs to be discussed further since both have consequences.
But i wouldn’t mind PHP switching to some kind of documenting technique like for example ExtJS does where specific new documentation gets generated with each minor version release like 1.1, 2.0, 2.1 and 2.2 had. I can’t count the times that I’ve run into problems only to consult the docs and noticing that somewhere down the page it states that argument X only got added in PHP 5.2 and i’m using 5.1.
I for example always know with what version of PHP i’m working so if i’m developing a project for 5.2 i’d consult the 5.2 docs, if i’m developing a project for 6 i’d consult the 6 docs and know exactly what order the arguments would be in or what functions are depricated and what other functions to use.
That being said i’d like to say that indeed for projects like let’s say PhpMyAdmin backwards compatibility could be a major problem but hey … how many project nowadays only work with PHP5? I don’t see any problem releasing projects in the future that require PHP6 and the new, better function naming and argument order.
It’s a tricky subject but with what I know now I’d prefer just fixing the existing functions in 6 and support the 5 branch a little longer.
[...] read Chris’ blog post and spread the word. Off course it’s the PHP developers who should share their opinion and if [...]