Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52483
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.211.66 cause and error)
To: Larry Garfield <larry@garfieldtech.com>
Cc: internals@lists.php.net
In-Reply-To: <4DD693BB.7030300@garfieldtech.com>
References: <4DD693BB.7030300@garfieldtech.com>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 20 May 2011 18:33:18 +0200
Message-ID: <1305909198.1318.13.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Porting PECL to userspace
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

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