Re: Porting PECL to userspace

Hi, On Fri, 2011-05-20 at 11:15 -0500, Larry Garfield wrote: > 1) Is this even a viable approach? It seems like it, but to my > knowledge no one else has done this to any serious extent which makes me > wonder if there's a reason the road less traveled is less traveled. This is a case by case thing. Most modules talk to a C library. You'd have to recreate the functionality. Some things can be done. Some things can be done but will be slooooowww. Some things won't work. > 2) Is anyone else doing this? No sense doing it ourselves if someone > else already is. There are some things where a similar solution exists already in PEAR or some other repository. They often have a different interface (leveraging PHP while extensions are formed more or less after a C lib) but can easily be swapped. > 3) What would be the cleanest way to do so? Case by case. > We had the thought of > partially automating the process by having PHP auto-generate at the very > least the subs of any classes and functions that the module provides. > However, when my colleague tried using the same parser as is used for > generating documentation he says he got several times as many classes as > the manual says the module has. We were using the PECL HTTP module as > our sample (http://www.php.net/http). (I don't know the exact details > of what he did at the moment.) Is that not a viable approach? Would we > be better off using reflection? Is there some other tool we're not > aware of? Well, HTTP is a doable case, I assume. Creating stubs from reflection shouldn't be too hard. While lots of HTTP classes already exist. Why build yet another one? In other cases I think you shouldn't follow necessarily the extensions interface but build one that makes sense[tm]. > If viable I'd love if this would start a trend, but we'll see where it > goes. I know it wouldn't work for all PECL modules, obviously, but I > suspect it could work for several, and provide an easy way for different > PHP projects to share backend code without needing lots of C developers. Well, in general PHP is grown-up and usable enough that more and more stuff can be done in pure PHP. Main reasons for using C are that existing C libraries can be used and C code is still way faster. Look at the stuff frameworks provide ... the way should actually be the other way round than what you describe: Stuff is done in PHP andportedtoC when needed. johannes