hi, On Thu, Jan 8, 2015 at 3:41 AM, Benjamin Eberlei <kont...@beberlei.de> wrote: > > > On Wed, Jan 7, 2015 at 11:14 PM, François Laupretre <franc...@tekwire.net> > wrote: >> >> > De : Pierre Joye [mailto:pierre....@gmail.com] >> > >> > ... here, >> > it is proposed to bundle scripts that will be executed at runtime like >> > any >> > other script, except that nothing can be done with them, not even >> > disable >> > them if not required (like using its own glue codes). >> >> I agree. Bundling scripts in extensions to execute them at each RINIT is, >> IMO, not a good idea (mostly for performance reasons and lack of control, as >> you note), but I keep thinking that a mechanism to embed PHP scripts in >> extensions and make them available via a common stream wrapper can be >> useful. What I don't like is the fact to execute them automatically at every >> RINIT. I prefer to let the extension free to load its PHP code when its >> logic decides it is needed. > > > To be honest, I don't see the use case of shipping optional PHP code inside > an extension. As the user of an extension I want all the functions/classes > to be available all the time, no matter if the extension developer wrote > everything in C or in PHP. > > For optional code there is Composer/PEAR/php include path, this is already a > solved problem.
So you are saying that people should be forced to use your glue code instead of implementing their own when it fits better? I can only disagree. But even then, it does not make the bundling of php code in binaries a smart idea. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
