Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62389
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender)
Date: Wed, 22 Aug 2012 09:06:47 +0200
To: Lars Schultz <lars.schultz@toolpark.com>
Cc: internals@lists.php.net
Message-ID: <2318376F24EC4B76AD4828C7F8E62B46@gmail.com>
In-Reply-To: <5032A163.9040500@toolpark.com>
References: <5032A163.9040500@toolpark.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Subject: Re: [PHP-DEV] Official Userland Library (was: removing an item
 from an array)
From: christoph.hochstrasser@gmail.com (Christoph Hochstrasser)

Hi,

I find this idea awesome=21 We could maybe take some inspiration from oth=
er communities, for example Ruby. In Ruby there's the =22Ruby Standard Li=
brary=22 (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 direc=
tly put it into =22php-src=22, or provide it via with a PEAR/Composer pac=
kage. The Ruby community also plans to unbundle the Userland Standard Lib=
rary from the distribution, to make it accessible for other Ruby implemen=
tations (which would be in our case also good). So I guess it would be be=
st to ship PHP's Userland Standard Library as collection of functions, in=
stalled as PEAR package by default, just like PHP=5FArchive. =20

If it's installed as a default PEAR package, then the library would alrea=
dy be within PHP's include path by default, so the user could just =22req=
uire=22 the needed modules. =46or example:

require=5Fonce =22stdlib/strings=22;

if (strings=5CstartsWith(=24foo, =22bar=22)) =7B
// ...
=7D

I think the Userland standard lib should be structured in reasonable name=
spaces (=22net=22, =22arrays=22, =22strings=22,=E2=80=A6) 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 =20
   userland standard library.
 * Consistent conventions for error handling
 * Rule out, how the user should use the code. Require individual modules=
 or =20
   include everything with one =22require=22=3F
 * The Userland Standard Library available as PEAR/composer package.
 * R=46C ruling out the way to ship the Userland Standard Library with th=
e PHP distribution.

-- =20
Christoph Hochstrasser

=E2=9D=96 http://twitter.com/hochchristoph =E2=9D=96 http://christophh.ne=
t =E2=9D=96 https://github.com/CHH =E2=9D=96


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 i=
nto
> > the core, if you can achieve exactly the same without core changes=3F=

> > =20
> =20
> =20
> =20
> This comment from Sebastian got me thinking. It's true. Every-someone =20
> has his own views on what is absolutely necessary and should be =20
> available to every-one. Depending on ones coding style, it probably is =
=20
> absolutely necessary.
> =20
> Whenever a userland implementation is viable, it becomes a strong =20
> argument against embedding it within the core.
> =20
> But those suggestions keep coming up and some create more than a little=
 =20
> controversy among the contributors to the list and even among the =20
> core-developers. That said:
> =20
> Why dont we embed a library of userland code right there in the =20
> documentation, next to the core code, where a php-user would expect or =
=20
> look for the functionality. They'd have to be properly highlighted as =20
> userland implementations of course but would still be there to be found=
 =20
> in the documentation. This would at least solve the problem of:
> =20
> - =22horrible=22 implementations, replaced by neatly formed official =20
> userland solutions.
> - performance (because they would be as efficient as possible)
> - correctness (because discussed on the internals (or docs) list, almos=
t =20
> as if it'd go into the core)
> - skill (because everyone can provide a solution, even if he's not able=
 =20
> to write c-code)
> - availability (because with a simple copy/paste-action I can use the =20
> provided (currently) official solution immediately.
> =20
> It sounds a lot like PEAR, I guess...but I wouldn't consider PEAR a =20
> source for a userland implementation of, say, array=5Fremove or =20
> print=5Fr=5Fhtml. Also its alot more accessible and available than PECL=
, =20
> because it is after all just PHP code.
> =20
> I am not sure wether this is a good idea, but it struck me as a better =
=20
> solution than just saying: it's so simple, do it yourself.
> =20
> =20
> -- =20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> =20