Hi, On Jan 7, 2015 5:02 PM, "Derick Rethans" <der...@php.net> wrote: > > On Tue, 6 Jan 2015, François Laupretre wrote: > > > > De : Pierre Joye [mailto:pierre....@gmail.com] > > > > > 2. We have no easy way to actually release and deploy adhoc scripts, > > > used by a given extension > > > > > > For 2., it is one of the thing I can imagine implementing in pickle. > > > Or even better add it a s part of the build scripts and macros. Either > > > will work, even for binary install on windows f.e.. I would really > > > like to define a clear location relative to the extension directory. > > > This location will be used by this new feature, if implemented. I also > > > think that it should be either part of the current prepend setting, by > > > default and system only, or another setting. What I really consider as > > > a bad practice is any kind of bundling scripts in the extensions, that > > > will be a real pain to maintain and it opens some unknown can of > > > worms. Distros may also prefer to have that script outside the > > > extension, easier for cherry picks update when necessary (f.e. > > > security fixes). > > > > I am sorry to say that but, with all due respect, I have a totally opposite opinion. > > > > IMHO, this PHP code (and any other data we want to embed) is an > > integral part of the extension. A compiled extension is a consistent > > piece of code, it is contained in a single file and should not be > > split to separate files. > > That's very much the case. One extension, one "install". It doesn't > matter whether some of the extension is written in C, and other parts in > PHP. HHVM is *all* about this. Making use of C where you need it, and > otherwise just write the simpler *but integral* border functionality in > PHP for faster maintenance and development.
It is not correct nor relevant to compare hhvm extension development with this case. With hhvm it ends up with an actual native extension while here it is proposed to bundled script 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). Even zephir provides easy way to develop extension and again, it ends up with native code. The more arguments being brought in this thread the more I am convinced that we are trying to tackle the wrong problems.
