Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52485
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.28 cause and error)
Message-ID: <4DD69AB2.8050005@garfieldtech.com>
Date: Fri, 20 May 2011 11:45:38 -0500
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110414 SUSE/3.1.10 Thunderbird/3.1.10
MIME-Version: 1.0
To: internals@lists.php.net
References: <4DD693BB.7030300@garfieldtech.com> <1305909198.1318.13.camel@guybrush>
In-Reply-To: <1305909198.1318.13.camel@guybrush>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Porting PECL to userspace
From: larry@garfieldtech.com (Larry Garfield)

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