Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62314
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.26.187 cause and error)
Message-ID: <5032A880.9050500@lsces.co.uk>
Date: Mon, 20 Aug 2012 22:13:36 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120604 Firefox/13.0 SeaMonkey/2.10
MIME-Version: 1.0
To: PHP internals <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: lester@lsces.co.uk (Lester Caine)

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.
>
> 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.

Boilerplates on how to do more complex operations sounds a very good idea to me. 
It's exactly the sort of thing I've been asking for ... especially now that the 
vast majority of third party tutorials are no longer suitable? Rasmus has 
pointed out the same problem only in the last hour, and while trying to sort my 
own mysqlnd compile problem, the number of totally out of data results from 
google just re-enforce that situation.

Even PEAR is little use as a good example of coding style since it needs to be 
updated to be strict compliant in a tidy way - rather than just fire fighting 
error messages.

Using them as a replacement for tidying up core functions may be a little 
controversial, but it does seem the ideal idea for archiving the excellent 
examples that have been presented on the various lists? If they then form the 
base for an update to a core function, then the boilerplates just get updated to 
be current.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk