Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80294
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADajX4BOHtNDjUpa8QXj8qXkQ8Zj+T=tpzab1Bfswb1nyfS8Rw@mail.gmail.com>
References: <CAEPJdu=2oWiSCQOTkO1g5QDs4NrJwd5H14Jks17qrNu7-eQNVg@mail.gmail.com>
	<54AE7340.6080708@fedoraproject.org>
	<CAEPJdu=jLHTmHsWjV8bSAtj9Pa+R_z5ZY3RQf85tM4DStQ7YZw@mail.gmail.com>
	<CADajX4BOHtNDjUpa8QXj8qXkQ8Zj+T=tpzab1Bfswb1nyfS8Rw@mail.gmail.com>
Date: Thu, 8 Jan 2015 17:48:45 -0800
Message-ID: <CAEZPtU78Tw17MxV-dawr=-YBY1LDNnV36vpU3igw9L_7cuJBGw@mail.gmail.com>
To: Adam Harvey <aharvey@php.net>
Cc: Benjamin Eberlei <kontakt@beberlei.de>, 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: pierre.php@gmail.com (Pierre Joye)

On Thu, Jan 8, 2015 at 10:46 AM, Adam Harvey <aharvey@php.net> wrote:
> 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 req=
uire
> access to any internal APIs.

This is something totally different to what we are talking about here.
Yes, such needs will benefit of having a script released with the
extension itself (in one form or another), but such hooks are really
something totally different.


> 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".

And he is wrong here. It is possible, today.

> 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, bec=
ause
> 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?

It is possible already, let make it even easier, no?

> 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 =
there.
>
>> 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.

Btw, closed source  extensions could be installed by the new pickle
too. While I do not consider closed PHP scripts source as relevant,
never did and most likely never will :)

Cheers,
--=20
Pierre

@pierrejoye | http://www.libgd.org