On 03/21/2007 04:15 PM, Richard Quadling wrote:
I agree. Because I can use 1 language to deal with web/cli/gui, I can
create classes which can be used in all 3 environments (though I'm not
GUI-ing at the moment). And from that single code base I can fix
multiple applications instantly without the need to recompile hundreds
of programs and libraries. I can potentially enhance all the
applications by adding new functionality. All sorts of good things.
Being interpreted and having multiple modes of operation is a
fantastic thing. I no longer write C/Delphi/BAT/sh scripts. I write
PHP classes and use them wherever I want/need. Testing via a CLI is a
lot easier sometimes than via a browser.
Though, I probably WOULDN'T to video encoding using userland PHP,
being able to do some things in userland PHP via an extension to a
library would be excellent.
The JEDI project for Delphi comes to mind
(http://www.delphi-jedi.org/). In its simplest form, the results of
the JEDI project is to allow Delphi to interact with any library.
Normally libraries have .h header files. But Delphi doesn't so the
JEDI project is a massive repository of code to allow you to interact
with these libraries.
JEDI extends the capabilities of Delphi considerably. And I doubt
everyone uses every new piece of functionality.
As a GSoC project idea, how about a mechanism to allow OS interaction
OUTSIDE of a PHP extension? I'm on windows, so that's what I know, but
not all things can be accessed from within PHP. But if there was a way
to "bind" to a particular library (like you would do in compilable
languages), then this could open PHP to a LOT more libraries a LOT
quicker and without the need to understand ALL the intricacies of
PHP's internals. Maybe.
You mean something like this?
http://pecl.php.net/package/ffi
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
