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:

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

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.

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.

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

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.

--

--
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?

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/