Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29770
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 63.205.162.114 as permitted sender)
Message-ID: <465744E0.7090306@zend.com>
Date: Fri, 25 May 2007 13:19:44 -0700
Organization: Zend Technologies
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Daevid Vincent <daevid@daevid.com>
CC:  internals@lists.php.net
References: <BRAKAum03yMJiQTyfPe00000c4e@mx1.lockdownnetworks.com>
In-Reply-To: <BRAKAum03yMJiQTyfPe00000c4e@mx1.lockdownnetworks.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHP needs better function organization, naming and
 parameter specifications
From: stas@zend.com (Stanislav Malyshev)

>> 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/