Hi, Nice to see my name not only in my signature ;)
I've not much to say right now, but what you wrote was slightly in my mind, when I wrote the other mail. I'll keep an eye on it (at least ;)). Regards, Sebastian 2012/8/20 Lars Schultz <lars.schu...@toolpark.com> > 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. > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
