Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62358
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain toolpark.com from 195.49.42.12 cause and error)
Message-ID: <5033F315.7010608@toolpark.com>
Date: Tue, 21 Aug 2012 22:44:05 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: internals@lists.php.net
CC: Andrew Faulds <ajf@ajf.me>
References: <5032A163.9040500@toolpark.com> <5032A35B.4020409@ajf.me>
In-Reply-To: <5032A35B.4020409@ajf.me>
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: lars.schultz@toolpark.com (Lars Schultz)

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.

> 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.

> 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.