On Thu, Jan 8, 2015 at 10:46 AM, Adam Harvey <ahar...@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 <kont...@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 — they're not performance-critical, and don't require > 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 > — you don't want to expose a stable API to userland for this, because > 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 — whatever form it ends up taking — 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, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
