Re: GSoC

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