Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:43580
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.46.29 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=DA6Z2faK8urJVjXweczaHTzgdL4LHGRjfBwxHdo8qYE7+XAJoYJ0SNoULafJWGRM14
         UhgrHFWHvx7bIRfLpjofmFIO++pscYfwkaL/4sYeiat7MUPiv/NfaHXMcnq9BFDc7G3N
         CjlWaM27dmx089mAmPf6eZXewhLkOLa6FjBsg=
MIME-Version: 1.0
In-Reply-To: <698DE66518E7CA45812BD18E807866CE02B86BCA@us-ex1.zend.net>
References: <af54caaf0903301606s26d87824oedd1167db8f0cc10@mail.gmail.com> 
	<698DE66518E7CA45812BD18E807866CE02B86BCA@us-ex1.zend.net>
Date: Wed, 1 Apr 2009 16:32:46 +0100
Message-ID: <af54caaf0904010832p657c2129g45c8a8feefaed234@mail.gmail.com>
To: Andi Gutmans <andi@zend.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC: Removing the Zend API
From: paul.biggar@gmail.com (Paul Biggar)

On Wed, Apr 1, 2009 at 3:35 PM, Andi Gutmans <andi@zend.com> wrote:
> Hi Paul,
>
> This is something I have considered in the past esp. as it would also red=
uce dependency of extensions on PHP runtime and make it easier for 3rd part=
ies to distribute PHP extensions which don't have to be rebuilt per-PHP ver=
sion. This is similar to JNI.


It is similar to JNI. This has been done many times before for many
languages, including Pythons Pyrex and ctypes, Ruby's FFI, Java's JNI
and JNA, and no doubt countless others. The only difference here is
that I recommend that we made this the _only_ interface (or as close
as we can make it) from the interpreter internals.



> There are some real challenges though and JNI is a good example of those =
challenges. In order to completely abstract the API from data structure you=
 need higher level API calls esp. for things like arrays and objects which =
typically incur a significant performance loss. JNI sucks big time on that =
front. Also it often leads to additional data copying.

All of this happens at the moment to marshal data into zvals. My RFC
does not intend to add to this complexity, but rather to make it work
exactly the same as it does now. So if currently a library avoids
copying values, it should be possible to keep that property. If the
library cannot currently avoid it, I do not expect to be able to avoid
it with a new scheme.

This is very much more important for PHP that JNI is to Java. Every
library shipped with PHP (including most of SPL I believe) is tightly
coupled to the interpreter. By contrast, the vast majority of Java's
Class library is written in Java.



> Also this doesn't necessarily have to replace the Zend API but in fact be=
 an engine independent API. Over time if everyone adopts then we could get =
rid of Zend API. However, if what I say above is correct, we may find that =
it's actually very complementary and that some core extensions prefer to ho=
ok into the engine very tightly while third parties (e.g. pdflib) and less =
core extensions prefer to stick to an independent API which can work across=
 not only mini release of PHP but also minor and in some cases major releas=
e of PHP.


It doesn't have to, but I think it should. But it would be insane to
expect a new scheme to replace the current one, unless it works
universally.

Core "extensions", like important array and string functions, will
probably need to be tightly coupled to the interpreter. Some other
extensions would too, like Xdebug. If people could suggest other
extensions which should not be decoupled, I would appreciate it.


> This API would need to be designed in great detail and we would need to m=
ake sure it is long lasting.

I could not agree more.



> My 2 cents.
> Andi

Thanks for the input, the more the merrier :)
Paul

>
>> -----Original Message-----
>> From: Paul Biggar [mailto:paul.biggar@gmail.com]
>> Sent: Monday, March 30, 2009 4:07 PM
>> To: PHP Internals
>> Subject: [PHP-DEV] RFC: Removing the Zend API
>>
>> Hi,
>>
>> I've added a new RFC to the wiki
>> (http://wiki.php.net/rfc/remove_zend_api). It details a plan to try
>> and decouple the Zend engine from the libraries, in order to allow
>> large scale changes to the Zend engine in the future. The RFC
>> describes a prototype phase of the project, which could reasonably be
>> done within a GSOC project, so I have added it to the GSOC 09 page
>> (http://wiki.php.net/gsoc/2009#prototyping_removal_of_the_zend_api).
>>
>> If anybody has any comments, I'd be delighted to hear them. If anybody
>> knows (or is) a good student looking for a GSOC project (and I've left
>> it late, there are only 3 days left to apply), please encourage the
>> student to look at this. Finally, if anybody is interested in helping
>> mentor this as part of the GSOC, I'd be grateful for the help (I have
>> to start writing my thesis soon).
>>
>> Thanks,
>> Paul
>>
>> --
>> Paul Biggar
>> paul.biggar@gmail.com
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



--=20
Paul Biggar
paul.biggar@gmail.com