") && endswith($line, "

Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62359
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 64.22.89.134 as permitted sender)
Message-ID: <5033F500.9090209@ajf.me>
Date: Tue, 21 Aug 2012 21:52:16 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Lars Schultz <lars.schultz@toolpark.com>
CC: internals@lists.php.net
References: <5032A163.9040500@toolpark.com> <5032A35B.4020409@ajf.me> <5033F315.7010608@toolpark.com>
In-Reply-To: <5033F315.7010608@toolpark.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Official Userland Library (was: removing an item from
 an array)
From: ajf@ajf.me (Andrew Faulds)

On 21/08/12 21:44, Lars Schultz wrote:
> Am 20.08.2012 22:51, schrieb Andrew Faulds:
>> On 20/08/12 21:43, Lars Schultz wrote:
>> It's a ridiculous argument, IMO. Nothing you could add to core couldn't
>> be implemented in userland code somehow. (yes, that's hyperbole, but
>> there is very often a userland solution. Most functions are for
>> convenience)
>
> I don't think it's ridiculous because every core functionality to be 
> implemented and maintained causes some php-dev to invest time on 
> something, which is not absolutely necessary because it could be done, 
> with some additional work, in userland. There is a lot of 
> functionality, that can not be reasonably well implemented in 
> userland, and php-dev time should be used on such cases, no?
>
> With my suggestion, any php-user could suggest a functionality he 
> feels is missing to go not into core but into the documentation, with 
> a suggestion of how to solve the problem. Therefore the bar, which 
> decides wether something is worthy of going into core could stay as 
> high as it is, but it could be lower for something that goes into the 
> documentation as an example.
>
The problem is that these functions often improve the readability and 
concise expressive power of PHP. Yes, you can import large libraries of 
functions, but it is much more programmer-friendly not to.

Also, functions can often improve the *maintainability* of code, as 
well. For instance, compare:

if (startswith($line, "<title>") && endswith($line, "</title>") {

with:

if (susbstr($line, 0, 7) === "<title>" && substr($line, -8) === 
"</title>") {

The first is more readable, and more maintainable, since you're not 
dealing with manually specified string lengths, which can easily be wrong.
>> Adding functions is important for convenience as well as functionality.
>> Sure, it would be nice to have a small set of functions, but those lead
>> to overly verbose code and waste the time of developers. Yes, many of
>> them can be easily implemented in userland, but consider this: what if
>> half (say) of the array or string functions didn't exist and you had to
>> manually implement each? A little code can quickly become a lot to do a
>> lot of simple things.
>
> Therein lies the crux of it all...how much is too much or too little. 
> Who's to say? It's a matter of personal preference, I believe. That's 
> why such features will always trigger those discussions. Because it 
> depends on one's programming style...of which there are various, 
> various good ones, even if not always compatible.
There seems to be a problem in here of "if I don't need it, nobody else 
does". Of course the reverse "if I need it, everyone else should have it 
in core" is also true, but I think the first point is a problem.
>
>> That said, not every possible function has a compelling case for
>> addition, simply because it does something too obscure or is 
>> impractical.
>
> Sometimes that is obvious and then the discussion will be short or not 
> even starts. But mostly it's not.
>
It quite often is obvious, I fear: the most vocal may often be the minority.

-- 
Andrew Faulds
http://ajf.me/