Re: Official Userland Library (was: removing an item from an array)
| From: | Lester Caine | Date: | Tue, 21 Aug 2012 21:20:51 +0000 |
| Subject: | Re: Official Userland Library (was: removing an item from an array) | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-62361@lists.php.net to get a copy of this message | ||
Lars Schultz wrote:
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. I run some model engineering sites ;)
especially now that the vast majority of third party tutorials are no longer suitable? Rasmus has pointed out the same problem only in theAre 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. No Rasmus Lerdorf was sorting out a problem for someone who was 'following a tutorial' which was no longer correct.
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. Exactly ...
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. Just spent the last two days getting a customers joomla sites working again ... first problem ... add error_reporting( E_ALL & ~E_STRICT & ~E_WARNING ); to the config file to hide all the errors and warnings.
-- 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.ukUsing 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. I'm still having trouble finding out the preferred way to use some of the basics - stuff I've used for years but now throws warnings :( And a clean boilerplate design without some of the esoteric bells and whistles would be nice.