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 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"?
* The Userland Standard Library available as PEAR/composer package.
* RFC ruling out the way to ship the Userland Standard Library with the PHP
distribution.
--
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
