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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
