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/hochchristophhttp://christophh.nethttps://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

Reply via email to