Re: Porting PECL to userspace

On 05/20/2011 11:33 AM, Johannes Schlüter wrote:

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

Well a non-small part of the goal here is to use an existing interface that is (presumably) used by people outside of our project, and to not have to rethink the interface ourselves. To an extent I'd prefer a non-perfect existing interface to a custom perfect interface. While certainly some PECL modules wouldn't make any sense in user space (no one is porting runkit to user space, naturally), I've seen a fair number of modules that are mostly socket wrappers to Solr, oAuth, etc. Those can be done, slower of course, in PHP. That's the use case I mostly see, where there's existing work that we can leverage if we can work around the "must have root" limitation on most hosts. If the long term result is that PECL gets more attention and usage as people realize the advantages of C-based code, even better. --Larry Garfield