Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62392
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.170 as permitted sender)
MIME-Version: 1.0
Sender: sebastian.krebs.berlin@gmail.com
In-Reply-To: <2318376F24EC4B76AD4828C7F8E62B46@gmail.com>
References: <5032A163.9040500@toolpark.com>
	<2318376F24EC4B76AD4828C7F8E62B46@gmail.com>
Date: Wed, 22 Aug 2012 09:31:37 +0200
Message-ID: <CALtuQzA72+CAtpCXPD3LYQ2NT2jTwpqxhff0THm6WgqvDcGJag@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=047d7b621c1ab1bdd804c7d5bb47
Subject: Re: [PHP-DEV] Official Userland Library (was: removing an item from
 an array)
From: krebs.seb@gmail.com (Sebastian Krebs)

--047d7b621c1ab1bdd804c7d5bb47
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2012/8/22 Christoph Hochstrasser <christoph.hochstrasser@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 wou=
ld
> be best to ship PHP's Userland Standard Library as collection of function=
s,
> 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",=E2=80=A6) and could also be a tes=
tbed 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
>
> =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
> 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, almos=
t
> > 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
>
>


--=20
github.com/KingCrunch

--047d7b621c1ab1bdd804c7d5bb47--