You are not forced to use the glue code, its just always available. That is what an extension is about, always available code. An option would of course be to not use the extension if you don't need it.
Developers can feel free to use the low level API just like PHP also ships high and low level stream functions for example. On Thu, Jan 8, 2015 at 12:43 PM, Pierre Joye <pierre....@gmail.com> wrote: > 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 >
