Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62311
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: <5032A163.9040500@toolpark.com>
Date: Mon, 20 Aug 2012 22:43:15 +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
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Official Userland Library (was: removing an item from an array)
From: lars.schultz@toolpark.com (Lars Schultz)

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.

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.