Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80293
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <31A3F47C-0C5B-46E0-8B34-2105F467FDB3@fredemmott.co.uk>
References: <CAEPJdu=2oWiSCQOTkO1g5QDs4NrJwd5H14Jks17qrNu7-eQNVg@mail.gmail.com>
	<CAESVnVqAHJujo0anMi7QYhSZeErcfRVAJ=M7oQMG-huk-bxpCg@mail.gmail.com>
	<54AAF98B.4020709@gmail.com>
	<alpine.DEB.2.11.1501061120440.4080@whisky.home.derickrethans.nl>
	<CAEZPtU69a2MwH5aqigAUEp8+KcjR+w9pd81EvzvM1_z4ES34rQ@mail.gmail.com>
	<001b01d029bb$fa687fc0$ef397f40$@tekwire.net>
	<alpine.DEB.2.11.1501070959000.4080@whisky.home.derickrethans.nl>
	<CAEZPtU67htboPTt6PefLaEREbkobnPY=BpjKpRGg3B1o8xC0Vg@mail.gmail.com>
	<31A3F47C-0C5B-46E0-8B34-2105F467FDB3@fredemmott.co.uk>
Date: Thu, 8 Jan 2015 17:44:20 -0800
Message-ID: <CAEZPtU7=EytMVfA22g-2AYT514s13VJdZ330niyo6rRiwHjFhg@mail.gmail.com>
To: Fred Emmott <fred@fredemmott.co.uk>
Cc: Derick Rethans <derick@php.net>, PHP internals <internals@lists.php.net>, 
	Sara Golemon <pollita@php.net>, Stanislav Malyshev <smalyshev@gmail.com>, 
	=?UTF-8?Q?Fran=C3=A7ois_Laupretre?= <francois@tekwire.net>, 
	Benjamin Eberlei <kontakt@beberlei.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Extension Prepend Files
From: pierre.php@gmail.com (Pierre Joye)

On Thu, Jan 8, 2015 at 9:56 AM, Fred Emmott <fred@fredemmott.co.uk> wrote:
>
>> On Jan 7, 2015, at 2:18 AM, Pierre Joye <pierre.php@gmail.com> wrote:
>>> That's very much the case. One extension, one "install". It doesn't
>>> matter whether some of the extension is written in C, and other parts i=
n
>>> PHP. HHVM is *all* about this. Making use of C where you need it, and
>>> otherwise just write the simpler *but integral* border functionality in
>>> PHP for faster maintenance and development.
>>
>> It is not correct nor relevant to compare hhvm extension development wit=
h
>> this case. With hhvm it ends up with an actual native extension while he=
re
>> it is proposed to bundled script that will be executed at runtime like a=
ny
>> other script, except that nothing can be done with them, not even disabl=
e
>> them if not required (like using its own glue codes).
>
>
> Both HHVM and its' extensions embed PHP source in the binaries.
>
> In our experience:
> + bundling them together makes it much quicker to iterate and improve ext=
ensions.

Releasing them together allows that. Bundling does not help to improve
extensions, eventually make it easier to install but that's about it.

> + the PHP code tends to use =E2=80=98non-public=E2=80=99 parts of the C A=
PI - so it really needs to be kept in sync with the PHP version. I=E2=80=99=
m not sure if composer currently supports =E2=80=98if I=E2=80=99m on PHP 5.=
6.0 use this library, if I=E2=80=99m on 5.6.1 use this library=E2=80=A6=E2=
=80=99. While this is fixable, it seems like a lot of boilerplate.
> + If PHP7 does develop a JIT, the PHP implementations could be faster tha=
n calling the C code (type specializing, and the overhead of setting up the=
 stack for a C function call). This is often the case for HHVM.

How does it help? For php, an extension will be built against a given
version. Unless a script per version is created, bundling script will
be of no help for extensions developers as most of the extensions can
be built against many versions.

I have no idea if there are custom hhvm extensions out there, but they
will have to deal with the same issue. How to make it work with
multiple version of hhvm.This is not the case now for the bundled
ones, they are kept in sync with hhvm directly, just like the core php
extensions are in sync with the engine changes.

Off topic: btw, how we want to deal with 5.x and 7.x from an extension
point of view is still a big question. Multiple branches, multiple src
files, multiple releases, etc.

> - we currently do not support extension-style parameter coercion in PHP f=
unctions; this leads to small incompatibilities in our case, which we usual=
ly address by writing a C++ function that proxies to a hidden PHP implement=
ation. For PHP7, if the current scalar types RFC lands, this won=E2=80=99t =
be a problem; if it doesn=E2=80=99t, there=E2=80=99s a chance that multiple=
 functions from the same extension will have confusingly different paramete=
r coercing behavior, depending on the author=E2=80=99s rigor.

I hope it will pass, we cruelly need that :)

> We solved some of the other problems by only allowing definitions, no sid=
e-effects - classes, constants, namespaces etc. We do not allow code outsid=
e of a function body here.

Yes, we will have to do that, no matter what we choose. I am however
not sure how to do it with the current engine design. Using
zend_compile (or a derived implementation) may help.

> HHVM-specific details (just FYI, agree that they=E2=80=99re probably not =
particularly relevant):
>
> * We do not translate the PHP source to native code (unless it ends up be=
ing jitted at runtime)

Which is very likely to be the case for codes used in many requests.
PHP does not have JIT, certainly not in 6.0, maybe in 6.x tho'

> * We=E2=80=99re planning on supporting the extension-style coercion in Ha=
ck code with a user attribute

All in all, I have a hard time to compare hhvm to php in this case. It
is not really PHP. hhvm is by design much more suited to allow that,
additional syntax and JIT make this whole thing a totally different
story.

The fact that hhvm implements a significant part of the extensions (or
other areas) using PHP+additional syntax as well as adding cleaner
APIs or mechanisms for the C parts only confirms me one thing: the
very 1st problem we have to solve is to ease the extension creation,
by drastically changing the internals APIs & tools. Bundling script
does not help here, we are using a scotch tape to repair something
that should have been replaced or redesigned since long already. I am
not blaming anyone, the engine design, historically, does not make
such changes easy.

Cheers,
Pierre