> 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

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to