On Sun, Jan 11, 2015 at 2:24 AM, Lester Caine <les...@lsces.co.uk> wrote:
> On 11/01/15 04:08, Sara Golemon wrote:
>> My idea is to cover *most* (but not all) extensions with a narrower,
>> simplified API. As you say, many interactions fall into the "marshal
>> this engine value to a C type as needed". This can cater to the
>> bread-and-butter of PHP extensions very well.
>
> Having a rather large reliance on Firebird, the fact that it gets pushed
> to the 'someone else will do that when they need it' pile is a little
> irritating. All the extension does is interfaces the Firebird Client to
> PHP and the majority of the times it has become unavailable are due to
> framework changes. Other extensions are currently in the same state on
> phpng? All database related.
>
I think I may have been unclear.
I don't mean that "those exceptional extensions should have to extend
the API themselves", I mean that not everything needs to be
expressible in a common language. I picked out runkit as an example
to illustrate this because it does /weird/ things. Database
connectors like ibase/firebird/etc... don't generally do those things.
The goal of this project is, in fact, to stop breaking simple
extensions like firebird/ibase who's only purpose is to bridge PHP to
C/C++. The framework they depend on should be solid enough that an
extension written for PHP 5.2 will work without having to make changes
on PHP7, 8, 15, etc... Depending on how we do it, we might even be
able to make it ABI compatible between versions, meaning you don't
even need to recompile between 5.2 and 7.0 (yes, that's a stretch
goal).
> HHVM has only recently started supporting the interbase extension, but I
> think does not have the fbird_ aliases which while there is still no
> break between firebird and interbase, this is an area which will change
> with the next generation of Firebird.
>
As an aside, if you've got a list of what needs aliasing, I can add
that this weekend. :) In HHVM, aliases a method literally looks
like:
function intlcal_get_repeated_wall_time_option(IntlCalendar $cal): int
{ return $cal->getRepeatedWallTimeOption(); }
> Alright we do have a couple of people who understand the PHP side enough
> to address the very small number of bugs that have affected the
> extension but it does need a programmer who understands the fundamental
> changes being made that is needed to port the still missing extensions :(
>
Again, the goal here is to NOT need those experts involved. An
extension written for 5.2 shouldn't have to care about changes in the
engine, it should only care that "I expect these C types when my API
is called, and I'm returning this C type". I don't want you to have
to know that zvals no longer store reference sementics directly. I
don't want you to have to deal with refcounting. I don't want you to
have to know when to separate and when not to just so that you can
convert some mixed type.
> I know you are only talking about the mechanism Sara, but some of us are
> still unable to even play with the current master on our framework
> because only 'most' extensions are currently supported.
>
I know. I'm one of 'em. This is partially coming out of my
frustrated attempts to #ifdef my way around making my extensions work
on PHP5 and PHP7 with the knowledge that the API is still shifting
under my feet. That's why I think it's time for a stable public API
which is independent from the engine.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
