Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62354
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: <5033EFA4.6050501@toolpark.com>
Date: Tue, 21 Aug 2012 22:29:24 +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
References: <5032A163.9040500@toolpark.com> <5032A880.9050500@lsces.co.uk>
In-Reply-To: <5032A880.9050500@lsces.co.uk>
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 23:13, schrieb Lester Caine:
> 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 ...
I am glad you like the idea!;) although "boilerplate" does seem to leave 
a metallic aftertaste in my mouth.

> especially now that the vast majority of third party tutorials are no
> longer suitable? Rasmus has pointed out the same problem only in the
Are you referring to "Rasmus Schultz" from the "removing an item from an 
array" thread? As far as I understood, Rasmus is arguing in favor of 
having more functionality built into core, while I am arguing, that a 
lot of functionality should go into the documentation first, as a 
userland implementation. I am not sure I understand what you're getting at.

> 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.
You mean that when you're googling you get bad results, because of the 
whitespread use of php? I know what you mean. If good and proven 
examples of common problems would be within the official documentation, 
no googling would be necessary.

> 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.
Personally I have never used PEAR, so I can't say anything about the 
situation there, but I can imagine that maintaining such a large 
codebase has it's disadvantages. This could probably happen to my idea 
as well...causing lots of necessary maintenance-work, I mean. But since 
its userland code, lots of people can work on the problem. Also the kind 
of code I'd like to see there is very concise and bare-bones, so it 
probably won't need much adjustment to new php-versions.

> 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.
>
That's something I thought of too. If some functionality becomes very 
popular (difficult to measure, I guess) it could go into core, AFTER 
it's proven its worth in real-world applications.