Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29726
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain l-i-e.com from 67.139.134.202 cause and error)
Message-ID: <34060.216.230.84.67.1180040141.squirrel@www.l-i-e.com>
In-Reply-To: <BRAKAum03yMJiQTyfPe00000c4e@mx1.lockdownnetworks.com>
References: <BRAKAum03yMJiQTyfPe00000c4e@mx1.lockdownnetworks.com>
Date: Thu, 24 May 2007 15:55:41 -0500 (CDT)
To: "Daevid Vincent" <daevid@daevid.com>
Cc: internals@lists.php.net
Reply-To: ceo@l-i-e.com
User-Agent: Hostbaby Webmail
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal
Subject: Re: [PHP-DEV] PHP needs better function organization,
      naming and parameter specifications
From: ceo@l-i-e.com ("Richard Lynch")

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?