2012/8/22 Christoph Hochstrasser <christoph.hochstras...@gmail.com> > Hi, > > I find this idea awesome! We could maybe take some inspiration from other > communities, for example Ruby. In Ruby there's the "Ruby Standard Library" ( > http://www.ruby-doc.org/stdlib-1.9.3/) which is a collection of classes > written in Ruby and shipped with the Ruby distribution. > > I imagine something similar for PHP, but I'm uncertain if we should > directly put it into "php-src", or provide it via with a PEAR/Composer > package. The Ruby community also plans to unbundle the Userland Standard > Library from the distribution, to make it accessible for other Ruby > implementations (which would be in our case also good). So I guess it would > be best to ship PHP's Userland Standard Library as collection of functions, > installed as PEAR package by default, just like PHP_Archive. > > If it's installed as a default PEAR package, then the library would > already be within PHP's include path by default, so the user could just > "require" the needed modules. For example: > > require_once "stdlib/strings"; > > if (strings\startsWith($foo, "bar")) { > // ... > } > > I think the Userland standard lib should be structured in reasonable > namespaces ("net", "arrays", "strings",…) and could also be a testbed for a > redesign of PHP's standard library. >
So much /sign! > > So what we need would be: > > * Design document outlining the principles of the intended structure for > the > userland standard library. > * Consistent conventions for error handling > * Rule out, how the user should use the code. Require individual modules > or > include everything with one "require"? > At least with composer you can use a kind of "autoloading": You can define files, that are always included, when the autoloaded is prepared. > * The Userland Standard Library available as PEAR/composer package. > I would prefer composer, but I guess it is more useful to provide both? For composer only a git repository and a composer.json is required, thus making a composer-package from a PEAR-package should be straight forward. > * RFC ruling out the way to ship the Userland Standard Library with the > PHP distribution. > With Composer (again ;)) every project defines the dependencies themself, thus no additional distribution required. > > -- > Christoph Hochstrasser > > ❖ http://twitter.com/hochchristoph ❖ http://christophh.net ❖ > https://github.com/CHH ❖ > > > Am Montag, 20. August 2012 um 22:43 schrieb 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. > > > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- github.com/KingCrunch
