Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80284
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain adamharvey.name designates 209.85.223.173 as permitted sender)
MIME-Version: 1.0
Sender: adam@adamharvey.name
In-Reply-To: <CAEPJdu=jLHTmHsWjV8bSAtj9Pa+R_z5ZY3RQf85tM4DStQ7YZw@mail.gmail.com>
References: <CAEPJdu=2oWiSCQOTkO1g5QDs4NrJwd5H14Jks17qrNu7-eQNVg@mail.gmail.com>
 <54AE7340.6080708@fedoraproject.org> <CAEPJdu=jLHTmHsWjV8bSAtj9Pa+R_z5ZY3RQf85tM4DStQ7YZw@mail.gmail.com>
Date: Thu, 8 Jan 2015 10:46:24 -0800
Message-ID: <CADajX4BOHtNDjUpa8QXj8qXkQ8Zj+T=tpzab1Bfswb1nyfS8Rw@mail.gmail.com>
To: Benjamin Eberlei <kontakt@beberlei.de>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Extension Prepend Files
From: aharvey@php.net (Adam Harvey)

I'm going to be a bit hazier than normal in this e-mail, for which I
apologise. People who know who I work for, you can probably guess the
parameters of the NDA I'm trying not to break here.

On 8 January 2015 at 04:38, Benjamin Eberlei <kontakt@beberlei.de> wrote:
<+1 on everything I snipped>
> Examples of good use-cases for this feature:
>
> 1. Low-Level MongoDB connection code in C, userland OOP API in PHP.
> 2. Low-Level Crypto code, simplified PHP functions (think ext/hash +
> ext/password)
> 3. Database Vendor Extensions in C + common DB abstraction in PHP (PDO2).
> 4. Low-Level Date handling, high level PHP code

Let me toss another use case onto the fire.

Imagine you have an extension that replaces the zend_execute_ex
pointer so it can fire hooks before and after a particular function is
called. You can write those hooks in C, but there's no actual reason
they need to be =E2=80=94 they're not performance-critical, and don't requi=
re
access to any internal APIs.

At that point, it would be nice to have a mechanism for shipping PHP
code with your C extension that doesn't require any external
dependencies. As Derick says, "pecl install foo", not "pecl install
foo && composer require foo/bar && some sort of startup code in
userland".

This code isn't optional: it's required for your extension to behave
properly. It's intimately tied to the exact extension you're shipping
=E2=80=94 you don't want to expose a stable API to userland for this, becau=
se
there's no need, and it's irrelevant for users anyway. Why not allow a
way for extension authors to ship this code as (hopefully) safe,
managed PHP instead of C, in a way that isn't reliant on tooling and
could allow version drift between the C and PHP code bases?

This isn't a new idea. We've talked on IRC about shipping bits of the
standard library as PHP code instead of C for years. Having this
mechanism =E2=80=94 whatever form it ends up taking =E2=80=94 would help th=
ere.

> I should rewrite the RFC and remove the implementation details, because
> essentially the solution could also be tooling based (vs code based).

It could, but I think there's a benefit in having a non-tooling based
way to do it. Much as I (genuinely) wish everything was open source
and could be installed through PECL, there are plenty of closed source
extensions for PHP.

Adam