Re: [RFC] Extension Prepend Files

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 — they're not performance-critical, and don't require 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 — 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? 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. Adam