Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62313
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: <5032A35B.4020409@ajf.me>
Date: Mon, 20 Aug 2012 21:51:39 +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>
In-Reply-To: <5032A163.9040500@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 20/08/12 21:43, Lars Schultz wrote:
> Am 20.08.2012 19:43, schrieb Sebastian Krebs:
>> What I don't understand is, why should every function goes directly into
>> the core, if you can achieve exactly the same without core changes?
>
> This comment from Sebastian got me thinking. It's true. Every-someone 
> has his own views on what is absolutely necessary and should be 
> available to every-one. Depending on ones coding style, it probably is 
> absolutely necessary.
>
> Whenever a userland implementation is viable, it becomes a strong 
> argument against embedding it within the core.
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)

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.

That said, not every possible function has a compelling case for 
addition, simply because it does something too obscure or is impractical.
>
> But those suggestions keep coming up and some create more than a 
> little controversy among the contributors to the list and even among 
> the core-developers. That said:
>
> Why dont we embed a library of userland code right there in the 
> documentation, next to the core code, where a php-user would expect or 
> look for the functionality. They'd have to be properly highlighted as 
> userland implementations of course but would still be there to be 
> found in the documentation. This would at least solve the problem of:
>
> - "horrible" implementations, replaced by neatly formed official 
> userland solutions.
> - performance (because they would be as efficient as possible)
> - correctness (because discussed on the internals (or docs) list, 
> almost as if it'd go into the core)
> - skill (because everyone can provide a solution, even if he's not 
> able to write c-code)
> - availability (because with a simple copy/paste-action I can use the 
> provided (currently) official solution immediately.
>
> It sounds a lot like PEAR, I guess...but I wouldn't consider PEAR a 
> source for a userland implementation of, say, array_remove or 
> print_r_html. Also its alot more accessible and available than PECL, 
> because it is after all just PHP code.
>
> I am not sure wether this is a good idea, but it struck me as a better 
> solution than just saying: it's so simple, do it yourself.
>
>


-- 
Andrew Faulds
http://ajf.me/