PHP needs better function organization, naming and parameter specifications

php.internals

Daevid Vincent

19 years ago
Hello guys/girls, I was told to send my suggestions to this list (and I'm offering my help/time too...) D.
> -----Original Message----- > From: Jay Blanchard [mailto:jblanchard@pocket.com] > Sent: Wednesday, May 23, 2007 1:58 PM > To: Daevid Vincent; php-general@lists.php.net > Subject: RE: [PHP] PHP needs better funtion organization, > naming and parameter specifications. WAS: Form Validation Issues > > [snip] ...several valid points... [/snip] > > Send this all to the developer's list
-----Original Message----- From: Daevid Vincent [mailto:daevid@daevid.com] Sent: Wednesday, May 23, 2007 1:55 PM To: php-general@lists.php.net Subject: [PHP] PHP needs better funtion organization, naming and parameter specifications. WAS: Form Validation Issues
> On Thursday 24 May 2007 00:51, Greg Donald wrote: > > As I watch PHP de-evolve into Java, I find myself wanting something > > lighter weight and with a smaller syntax. > > PHP has long since spawned into something uncontrollable. Compare the > number of functions (and its aliases) to eg Ruby. The string > functions in > particular are absolutely bloated, eg ltrim, trim & rtrim - > WTF. Why not just have trim() and have the option of specifying
whether
> left/right/both? The same goes for the case-sensitive and > case-insensitive versions of functions.
Amen. The other thing is why isn't there any consistency with the function names?! It seems they're just randomly picked by whatever developer decided to make it. Isn't there some governing body who can at least make things consistent? Examples: ========= isset() vs. is_null() htmlentities() vs html_entity_decode() (and why is there "htmlentities()" and "htmlentities" both listed here: http://us2.php.net/manual/en/ref.strings.php ) quoted_printable_decode() vs quotemeta() strnatcasecmp - Case insensitive string comparisons using a "natural order" algorithm strnatcmp - String comparisons using a "natural order" algorithm strncasecmp - Binary safe case-insensitive string comparison of the first n characters strncmp - Binary safe string comparison of the first n characters strcasecmp - Binary safe case-insensitive string comparison Why do we need all those. Use a 'binary' flag. And secondly, why does this have the word "case" instead of "i" like the other string functions use? Why do I have to do this extra function call when I bet a majority of the time this is what you want: $bar = 'HELLO WORLD!'; $bar = ucfirst(strtolower($bar)); // Hello world! Why can't ucfirst() have a parameter to do what I want. arsort() and asort() should be array_sort() and array_sort_reverse() natcasesort() should be array_sort_natural() with parameters to make it case insensitive. Same for the rest of the sort functions. Why isn't unlink() named file_delete() as that's what it does? It's counter-intuitive. Why do we need lchgrp() and chgrp() -- why do I care if it's a link or not? Use a parameter flag if this is really a concern for people. No specific examples, but I know I've run into this stuff before: Sometimes the needle is first, sometimes the haystack is. Sometimes the pattern and subject are out of order. Also simple things like naming conventions: The "ereg*" functions call it $string, but the "preg" functions call it $subject Etc... I'm sure I could list easily 50 or 100 more examples here, but the point is that PHP needs some structure and organization and a document/spec that says how functions should be named and the order of parameters, ideally with 'optional' ones to the end (much like they are now in most cases). I would like them all to be prefixed with the general category they're in, so it's easy to find them. Such as "array_*", "str_*", "file_*", "date_*"etc. I think someone should go through and make proper names for all the current functions, keeping "aliases" for the existing ones to what they are now (so as not to break everyone's code), but only show the new proper names in the manual so developers don't use the sloppy old names. That would at least start us on the right path to fixing this chaos. BTW, don't get me wrong, I LOVE PHP. I've used it every day for maybe 10 years now. I just don't think the current "methodology" (or lack thereof) can keep sustaining the growth of the releases. I also think it's increasingly confusing for new users to learn. I'm still confused and always referencing the docs for function names and parameter orders. If there needs to be a governing body for the naming, etc as mentioned, I'm happy to volunteer my time / talent. Contact me off list for resume, etc and set me up an SVN account and I'll bring my machette and get this fixed. :) Daevid Vincent http://daevid.com

Vlad Bosinceanu

19 years ago
I really don't think that would work. There's far too many inconsistencies with php. Take haystack/needle order in string functions: creating aliases won't fix that; change the order and half the web is gonna break. Perhaps forking php is a good idea here. Think it through, fix what's there to fix, don't make the same mistake all over again, have it run alongside the original. That might be dangerous for php tho. Or just live with it. V Daevid Vincent wrote:

Richard Lynch

19 years ago
Many of the function name idiosyncracies stem from PHP being a "glue" language to tie together disparate libraries. The function names are the same as in the libraries, so one can read the docs for the libraries (eg mysql) and not have to "guess" what the function got renamed to in PHP -- it's the same name as in the library. This is actually a feature, once you get used to it, for most of these functions. That said, I think SOME of these points are valid... PS I top-posted since the "thread" order was long ago destroyed in the below. On Wed, May 23, 2007 5:11 pm, Daevid Vincent wrote:
> Hello guys/girls, I was told to send my suggestions to this list (and > I'm offering my help/time too...) > > D. > >> -----Original Message----- >> From: Jay Blanchard [mailto:jblanchard@pocket.com] >> Sent: Wednesday, May 23, 2007 1:58 PM >> To: Daevid Vincent; php-general@lists.php.net >> Subject: RE: [PHP] PHP needs better funtion organization, >> naming and parameter specifications. WAS: Form Validation Issues >> >> [snip] ...several valid points... [/snip] >> >> Send this all to the developer's list > > -----Original Message----- > From: Daevid Vincent [mailto:daevid@daevid.com] > Sent: Wednesday, May 23, 2007 1:55 PM > To: php-general@lists.php.net > Subject: [PHP] PHP needs better funtion organization, naming and > parameter specifications. WAS: Form Validation Issues > >> On Thursday 24 May 2007 00:51, Greg Donald wrote: >> > As I watch PHP de-evolve into Java, I find myself wanting >> something >> > lighter weight and with a smaller syntax. >> >> PHP has long since spawned into something uncontrollable. Compare >> the >> number of functions (and its aliases) to eg Ruby. The string >> functions in >> particular are absolutely bloated, eg ltrim, trim & rtrim - >> WTF. Why not just have trim() and have the option of specifying > whether >> left/right/both? The same goes for the case-sensitive and >> case-insensitive versions of functions. > > Amen. > > The other thing is why isn't there any consistency with the function > names?! It seems they're just randomly picked by whatever developer > decided to make it. Isn't there some governing body who can at least > make things consistent? > > Examples: > ========= > isset() vs. is_null() > > htmlentities() vs html_entity_decode() > (and why is there "htmlentities()" and "htmlentities" both listed > here: > http://us2.php.net/manual/en/ref.strings.php ) > > quoted_printable_decode() vs quotemeta() > > strnatcasecmp - Case insensitive string comparisons using a "natural > order" algorithm > strnatcmp - String comparisons using a "natural order" algorithm > strncasecmp - Binary safe case-insensitive string comparison of the > first n characters > strncmp - Binary safe string comparison of the first n characters > strcasecmp - Binary safe case-insensitive string comparison > > Why do we need all those. Use a 'binary' flag. And secondly, why does > this have the word "case" instead of "i" like the other string > functions > use? > > Why do I have to do this extra function call when I bet a majority of > the time this is what you want: > $bar = 'HELLO WORLD!'; > $bar = ucfirst(strtolower($bar)); // Hello world! > Why can't ucfirst() have a parameter to do what I want. > > arsort() and asort() should be array_sort() and array_sort_reverse() > > natcasesort() should be array_sort_natural() with parameters to make > it > case insensitive. Same for the rest of the sort functions. > > Why isn't unlink() named file_delete() as that's what it does? > It's counter-intuitive. > > Why do we need lchgrp() and chgrp() -- why do I care if it's a link or > not? > Use a parameter flag if this is really a concern for people. > > No specific examples, but I know I've run into this stuff before: > Sometimes the needle is first, sometimes the haystack is. > Sometimes the pattern and subject are out of order. > > Also simple things like naming conventions: > The "ereg*" functions call it $string, > but the "preg" functions call it $subject > > Etc... > > I'm sure I could list easily 50 or 100 more examples here, but the > point > is that PHP needs some structure and organization and a document/spec > that says how functions should be named and the order of parameters, > ideally with 'optional' ones to the end (much like they are now in > most > cases). I would like them all to be prefixed with the general category > they're in, so it's easy to find them. Such as "array_*", "str_*", > "file_*", "date_*"etc. > > I think someone should go through and make proper names for all the > current functions, keeping "aliases" for the existing ones to what > they > are now (so as not to break everyone's code), but only show the new > proper names in the manual so developers don't use the sloppy old > names. > That would at least start us on the right path to fixing this chaos. > > BTW, don't get me wrong, I LOVE PHP. > I've used it every day for maybe 10 years now. > I just don't think the current "methodology" (or lack thereof) can > keep > sustaining the growth of the releases. I also think it's increasingly > confusing for new users to learn. I'm still confused and always > referencing the docs for function names and parameter orders. > > If there needs to be a governing body for the naming, etc as > mentioned, > I'm happy to volunteer my time / talent. Contact me off list for > resume, > etc and set me up an SVN account and I'll bring my machette and get > this > fixed. :) > > Daevid Vincent > http://daevid.com > > >> -----Original Message----- >> From: Daevid Vincent [mailto:daevid@daevid.com] >> Sent: Wednesday, May 23, 2007 3:08 PM >> Cc: 'Crayon Shin Chan' >> Subject: RE: [PHP] PHP needs better funtion organization, >> naming and parameter specifications. WAS: Form Validation Issues >> >> > > Send this all to the developer's list >> > >> > Too late now. The damage has been done. Fixing all the >> > inconsistencies >> > would either break backward compatibility or introduce a >> > whole raft of yet more aliases. >> >> That's what I suggest: >> >> We rename th functions to proper names. >> >> Then we make aliases for the existing ones. >> >> We only publish the proper (new) names in the docs, so people >> don't use the old ones anymore. >> >> We publish a list of depricated names. >> >> Then we say by PHP7, the old ones are no longer supported. It >> should be effectively a simple search and replace for people >> to migrate code that's in use. And old code that's not active >> won't matter by PHP7 timeframe anyways. >> >> > Rasmus should have applied strict controls right from the >> beginning. >> > Instead what we have now is a hodgepodge of contributors, >> > each with the >> > own naming schemes and a whole bunch of functions with >> > immemorable names. >> >> Agreed. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So?

Stanislav Malyshev

19 years ago
>> number of functions (and its aliases) to eg Ruby. The string >> functions in >> particular are absolutely bloated, eg ltrim, trim & rtrim - >> WTF. Why not just have trim() and have the option of specifying > whether >> left/right/both? The same goes for the case-sensitive and >> case-insensitive versions of functions.
Why having parameter is better? Or, conversely, why having three functions is so bad? OK, the code would be a bit bigger and the hashtable would be a bit bigger, but so what? It won't have any measurable performance effect, so why bother?
> The other thing is why isn't there any consistency with the function > names?! It seems they're just randomly picked by whatever developer > decided to make it. Isn't there some governing body who can at least > make things consistent?
Well, there is a standard e.g. for prefixing, but some functions were born before it was born.
> Examples: > ========= > isset() vs. is_null()
Isset is not really a function, it's an operator. Same for empty(). is_* are functions checking variable types (while "set" is not really a type).
> htmlentities() vs html_entity_decode()
Well, maybe it would be better to have all of them have html_* form, but BC...
> (and why is there "htmlentities()" and "htmlentities" both listed here: > http://us2.php.net/manual/en/ref.strings.php )
I see only one entry.
> quoted_printable_decode() vs quotemeta()
Same as above - BC.
> Why do we need all those. Use a 'binary' flag. And secondly, why does > this have the word "case" instead of "i" like the other string functions > use?
(*) As above - I see no compelling reason why ton of options is better than ton of functions.
> Why do I have to do this extra function call when I bet a majority of > the time this is what you want: > $bar = 'HELLO WORLD!'; > $bar = ucfirst(strtolower($bar)); // Hello world! > Why can't ucfirst() have a parameter to do what I want.
We can't really have parameters for every special case, can we?
> arsort() and asort() should be array_sort() and array_sort_reverse()
Here adding alias seems to be a good idea.
> natcasesort() should be array_sort_natural() with parameters to make it > case insensitive. Same for the rest of the sort functions.
Maybe an alias here too.
> Why isn't unlink() named file_delete() as that's what it does? > It's counter-intuitive.
It's maybe counterintuitive for you, but not for anybody having any experience with Unix. Intuition differs.
> Why do we need lchgrp() and chgrp() -- why do I care if it's a link or > not?
Because that's how Unix works.
> Use a parameter flag if this is really a concern for people.
See (*).
> No specific examples, but I know I've run into this stuff before: > Sometimes the needle is first, sometimes the haystack is. > Sometimes the pattern and subject are out of order. > > Also simple things like naming conventions: > The "ereg*" functions call it $string, > but the "preg" functions call it $subject
OK, but why do you care - isn't it clear what the meaning is?
> I'm sure I could list easily 50 or 100 more examples here, but the point > is that PHP needs some structure and organization and a document/spec
There is. See CODING_STANDARDS.
> I think someone should go through and make proper names for all the > current functions, keeping "aliases" for the existing ones to what they > are now (so as not to break everyone's code), but only show the new > proper names in the manual so developers don't use the sloppy old names.
We can't remove old names from the manual since then it would not be possible to understand old code. We could, of course, put notes that explain which ones is better to use. If you are interested in it, I would propose to make a list - what you would like to rename to what, and see how people here feel about it.
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/