# Official Userland Library (was: removing an item from an array) - Thread: https://externals.io/message/62311 - Original archive: https://news-web.php.net/php.internals/62311 - Started by Lars Schultz on 2012-08-20T20:43:15+00:00 - Messages: 13 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #62311 — Lars Schultz — 2012-08-20T20:43:15+00:00 URL: https://externals.io/message/62311#62311 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. --- ## #62313 — Andrew Faulds — 2012-08-20T20:51:39+00:00 URL: https://externals.io/message/62311#62313 · In reply to: #62311 > Am 20.08.2012 19:43, schrieb Sebastian Krebs: > > […] > > 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. It's a ridiculous argument, IMO. Nothing you could add to core couldn't be implemented in userland code somehow. (yes, that's hyperbole, but there is very often a userland solution. Most functions are for convenience) Adding functions is important for convenience as well as functionality. Sure, it would be nice to have a small set of functions, but those lead to overly verbose code and waste the time of developers. Yes, many of them can be easily implemented in userland, but consider this: what if half (say) of the array or string functions didn't exist and you had to manually implement each? A little code can quickly become a lot to do a lot of simple things. That said, not every possible function has a compelling case for addition, simply because it does something too obscure or is impractical. > > 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. > > -- Andrew Faulds http://ajf.me/ --- ## #62314 — Lester Caine — 2012-08-20T21:13:36+00:00 URL: https://externals.io/message/62311#62314 · In reply to: #62311 Lars Schultz wrote: > Am 20.08.2012 19:43, schrieb Sebastian Krebs: > > […] > > 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. Boilerplates on how to do more complex operations sounds a very good idea to me. It's exactly the sort of thing I've been asking for ... especially now that the vast majority of third party tutorials are no longer suitable? Rasmus has pointed out the same problem only in the last hour, and while trying to sort my own mysqlnd compile problem, the number of totally out of data results from google just re-enforce that situation. Even PEAR is little use as a good example of coding style since it needs to be updated to be strict compliant in a tidy way - rather than just fire fighting error messages. Using them as a replacement for tidying up core functions may be a little controversial, but it does seem the ideal idea for archiving the excellent examples that have been presented on the various lists? If they then form the base for an update to a core function, then the boilerplates just get updated to be current. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #62354 — Lars Schultz — 2012-08-21T20:29:24+00:00 URL: https://externals.io/message/62311#62354 · In reply to: #62314 Am 20.08.2012 23:13, schrieb Lester Caine: > Boilerplates on how to do more complex operations sounds a very good > idea to me. It's exactly the sort of thing I've been asking for ... I am glad you like the idea!;) although "boilerplate" does seem to leave a metallic aftertaste in my mouth. > especially now that the vast majority of third party tutorials are no > longer suitable? Rasmus has pointed out the same problem only in the Are you referring to "Rasmus Schultz" from the "removing an item from an array" thread? As far as I understood, Rasmus is arguing in favor of having more functionality built into core, while I am arguing, that a lot of functionality should go into the documentation first, as a userland implementation. I am not sure I understand what you're getting at. > last hour, and while trying to sort my own mysqlnd compile problem, the > number of totally out of data results from google just re-enforce that > situation. You mean that when you're googling you get bad results, because of the whitespread use of php? I know what you mean. If good and proven examples of common problems would be within the official documentation, no googling would be necessary. > Even PEAR is little use as a good example of coding style since it needs > to be updated to be strict compliant in a tidy way - rather than just > fire fighting error messages. Personally I have never used PEAR, so I can't say anything about the situation there, but I can imagine that maintaining such a large codebase has it's disadvantages. This could probably happen to my idea as well...causing lots of necessary maintenance-work, I mean. But since its userland code, lots of people can work on the problem. Also the kind of code I'd like to see there is very concise and bare-bones, so it probably won't need much adjustment to new php-versions. > Using them as a replacement for tidying up core functions may be a > little controversial, but it does seem the ideal idea for archiving the > excellent examples that have been presented on the various lists? If > they then form the base for an update to a core function, then the > boilerplates just get updated to be current. > That's something I thought of too. If some functionality becomes very popular (difficult to measure, I guess) it could go into core, AFTER it's proven its worth in real-world applications. --- ## #62357 — Sebastian Krebs — 2012-08-21T20:40:08+00:00 URL: https://externals.io/message/62311#62357 · In reply to: #62311 Hi, Nice to see my name not only in my signature ;) I've not much to say right now, but what you wrote was slightly in my mind, when I wrote the other mail. I'll keep an eye on it (at least ;)). Regards, Sebastian 2012/8/20 Lars Schultz > Am 20.08.2012 19:43, schrieb Sebastian Krebs: > > > […] > > 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. --- ## #62358 — Lars Schultz — 2012-08-21T20:44:05+00:00 URL: https://externals.io/message/62311#62358 · In reply to: #62313 Am 20.08.2012 22:51, schrieb Andrew Faulds: > > It's a ridiculous argument, IMO. Nothing you could add to core couldn't > be implemented in userland code somehow. (yes, that's hyperbole, but > there is very often a userland solution. Most functions are for > convenience) I don't think it's ridiculous because every core functionality to be implemented and maintained causes some php-dev to invest time on something, which is not absolutely necessary because it could be done, with some additional work, in userland. There is a lot of functionality, that can not be reasonably well implemented in userland, and php-dev time should be used on such cases, no? With my suggestion, any php-user could suggest a functionality he feels is missing to go not into core but into the documentation, with a suggestion of how to solve the problem. Therefore the bar, which decides wether something is worthy of going into core could stay as high as it is, but it could be lower for something that goes into the documentation as an example. > Adding functions is important for convenience as well as functionality. > Sure, it would be nice to have a small set of functions, but those lead > to overly verbose code and waste the time of developers. Yes, many of > them can be easily implemented in userland, but consider this: what if > half (say) of the array or string functions didn't exist and you had to > manually implement each? A little code can quickly become a lot to do a > lot of simple things. Therein lies the crux of it all...how much is too much or too little. Who's to say? It's a matter of personal preference, I believe. That's why such features will always trigger those discussions. Because it depends on one's programming style...of which there are various, various good ones, even if not always compatible. > That said, not every possible function has a compelling case for > addition, simply because it does something too obscure or is impractical. Sometimes that is obvious and then the discussion will be short or not even starts. But mostly it's not. --- ## #62359 — Andrew Faulds — 2012-08-21T20:52:16+00:00 URL: https://externals.io/message/62311#62359 · In reply to: #62358 > Am 20.08.2012 22:51, schrieb Andrew Faulds: > > […] > > I don't think it's ridiculous because every core functionality to be > implemented and maintained causes some php-dev to invest time on > something, which is not absolutely necessary because it could be done, > with some additional work, in userland. There is a lot of > functionality, that can not be reasonably well implemented in > userland, and php-dev time should be used on such cases, no? > > With my suggestion, any php-user could suggest a functionality he > feels is missing to go not into core but into the documentation, with > a suggestion of how to solve the problem. Therefore the bar, which > decides wether something is worthy of going into core could stay as > high as it is, but it could be lower for something that goes into the > documentation as an example. > The problem is that these functions often improve the readability and concise expressive power of PHP. Yes, you can import large libraries of functions, but it is much more programmer-friendly not to. Also, functions can often improve the *maintainability* of code, as well. For instance, compare: if (startswith($line, "") && endswith($line, "") { with: if (susbstr($line, 0, 7) === "" && substr($line, -8) === "") { The first is more readable, and more maintainable, since you're not dealing with manually specified string lengths, which can easily be wrong. > > […] > > Therein lies the crux of it all...how much is too much or too little. > Who's to say? It's a matter of personal preference, I believe. That's > why such features will always trigger those discussions. Because it > depends on one's programming style...of which there are various, > various good ones, even if not always compatible. There seems to be a problem in here of "if I don't need it, nobody else does". Of course the reverse "if I need it, everyone else should have it in core" is also true, but I think the first point is a problem. > > > […] > > Sometimes that is obvious and then the discussion will be short or not > even starts. But mostly it's not. > It quite often is obvious, I fear: the most vocal may often be the minority. -- Andrew Faulds http://ajf.me/ --- ## #62361 — Lester Caine — 2012-08-21T21:20:51+00:00 URL: https://externals.io/message/62311#62361 · In reply to: #62354 Lars Schultz wrote: > Am 20.08.2012 23:13, schrieb Lester Caine: > > […] > I am glad you like the idea!;) although "boilerplate" does seem to leave a > metallic aftertaste in my mouth. I run some model engineering sites ;) > > […] > Are you referring to "Rasmus Schultz" from the "removing an item from an array" > thread? As far as I understood, Rasmus is arguing in favor of having more > functionality built into core, while I am arguing, that a lot of functionality > should go into the documentation first, as a userland implementation. I am not > sure I understand what you're getting at. No Rasmus Lerdorf was sorting out a problem for someone who was 'following a tutorial' which was no longer correct. > > […] > You mean that when you're googling you get bad results, because of the > whitespread use of php? I know what you mean. If good and proven examples of > common problems would be within the official documentation, no googling would be > necessary. Exactly ... > > […] > Personally I have never used PEAR, so I can't say anything about the situation > there, but I can imagine that maintaining such a large codebase has it's > disadvantages. This could probably happen to my idea as well...causing lots of > necessary maintenance-work, I mean. But since its userland code, lots of people > can work on the problem. Also the kind of code I'd like to see there is very > concise and bare-bones, so it probably won't need much adjustment to new > php-versions. Just spent the last two days getting a customers joomla sites working again ... first problem ... add error_reporting( `E_ALL` & ~E_STRICT & ~E_WARNING ); to the config file to hide all the errors and warnings. > > […] > That's something I thought of too. If some functionality becomes very popular > (difficult to measure, I guess) it could go into core, AFTER it's proven its > worth in real-world applications. I'm still having trouble finding out the preferred way to use some of the basics - stuff I've used for years but now throws warnings :( And a clean boilerplate design without some of the esoteric bells and whistles would be nice. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #62362 — Sebastian Krebs — 2012-08-21T21:22:20+00:00 URL: https://externals.io/message/62311#62362 · In reply to: #62359 2012/8/21 Andrew Faulds > > > > […] > concise expressive power of PHP. Yes, you can import large libraries of > functions, but it is much more programmer-friendly not to. > Really? Use composer and you'll not feel any difference. Don't use composer and it will require a single 'include' from you. That is "much more user-unfriendly"? At the end in both cases you will not feel any difference. So where is this "readability and concise expressive power", that is no possible with already existing userland tools? > > Also, functions can often improve the *maintainability* of code, as well. > For instance, compare: > > if (startswith($line, "") && endswith($line, "") { > > with: > > if (susbstr($line, 0, 7) === "" && substr($line, -8) === > "") { > > The first is more readable, and more maintainable, since you're not > dealing with manually specified string lengths, which can easily be wrong. Yes, that are functions I can imagine can go into a php-based standard library. They can even be more efficient than the self-made solution (strncmp() is faster than `substr()` ;)) and the user of startsWith() and endsWith() doesn't even need to take care. > > Adding functions is important for convenience as well as functionality. > > […] > There seems to be a problem in here of "if I don't need it, nobody else > does". Of course the reverse "if I need it, everyone else should have it in > core" is also true, but I think the first point is a problem. > > > > […] > minority. > > > -- > Andrew Faulds > http://ajf.me/ > > > -- > > > > -- github.com/KingCrunch --- ## #62389 — Christoph Hochstrasser — 2012-08-22T07:06:47+00:00 URL: https://externals.io/message/62311#62389 · In reply to: #62311 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: > > […] > > > > 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. --- ## #62392 — Sebastian Krebs — 2012-08-22T07:31:37+00:00 URL: https://externals.io/message/62311#62392 · In reply to: #62389 2012/8/22 Christoph Hochstrasser > 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: > > > […] > into > > […] > > > > > -- > > > > -- github.com/KingCrunch --- ## #62393 — Lester Caine — 2012-08-22T07:45:20+00:00 URL: https://externals.io/message/62311#62393 · In reply to: #62389 Christoph Hochstrasser wrote: > In Ruby there's the "Ruby Standard Library" Isn't that more like PEAR anyway? But with a lot less options :) Personally I'm looking for a 'Official Userland Library' that provides EXAMPLES of how to do operations rather than yet another downloadable library. Something I can cut and past from into my own code when I need a widget and which provides a much more 'PHP approved' style to the code I'm using now. Putting this into PEAR is most definitely not what I need. I need to be able to see the code on-line. There are a few such 'samples' in the manual, but the user added ones tend to be messy, and finding them is rather hit and miss. I HAVE found good samples, but getting back to them can be a problem. So perhaps a samples index is all that is missing, and only index material that is clean and fully 'rules compliant'? Many examples in the user comments now throw deprecated errors which are the reason to be looking for alternatives anyway nowadays :( -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #62416 — Lars Schultz — 2012-08-23T07:14:21+00:00 URL: https://externals.io/message/62311#62416 · In reply to: #62393 Am 22.08.2012 09:45, schrieb Lester Caine: > Personally I'm looking for a 'Official Userland Library' that provides > EXAMPLES of how to do operations rather than yet another downloadable > library. Something I can cut and past from into my own code when I need > a widget and which provides a much more 'PHP approved' style to the code > I'm using now. Putting this into PEAR is most definitely not what I > need. I need to be able to see the code on-line. I guess as always, the deployment of this userland-library depends on the php-users personal preference. I agree with Lester in that I'd rather have it available online as a proven example of how to solve a very specific problem instead of loading yet another bunch of functions I might not even need, just for the sake of having them. But I guess we could have both. I am not sure we should have a hefty namespace attached to those functions though...it would of course make the situation of naming clashes less dire, but that could also be solved manually by copy/pasting and then renaming according to taste. This is the beauty of it all. Wether you want to make the functions available globally, grouped as a static class or using namespaces is left to the user. Making the "Library" available for download as a complete package or using PEAR/Composer could be a second project, no? Lets focus on how it could fit into the manual (or not) and then go on to how it could be served as a package? I'd really like some comments/thoughts from a php-dev on this...and maybe someone from docs?