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. > The first reason is that, if we consider a released extension as a > conceptual unit, the best way to protect its integrity is to store it > as a single file. Storing it as separate files brings a lot of > potential issues : files can be renamed, deleted, etc. Offline tools > like composer can take care of integrity but, from a final user pov, > it will never be as clear as a single file (.so for extensions, or > package for PHP software). +1 > The second reason, more important, is about inter-communication > between C and PHP. I understand the pov : it is easier to allow > distros to upgrade an extension's PHP code without upgrading the C > code. But, if we consider the PHP code as an integral part of the > extension, this should be avoided, as C and PHP code need to be kept > in sync. +1 > If you allow upgrading the PHP code only, you must consider them as > two separate pieces of code and, so, consider BC in the way they > communicate together. This is a perfectly valid scheme, but, in this > case, this PHP code is not part of your extension anymore, it is a > separate software with its own version/release numbering, which > communicates with your extension. If distros could cherry-pick the C > files they want to upgrade, depending on the features they want to > provide, would you be ready to keep BC between all your C files ? The > same if libc was distributed as a bunch of individually-upgradable > files, each defining a function, with consistency ensured by metadata > and an offline tool. > > So, to summarize my opinion : if an extension writer wants to > distribute part of his code in PHP and if he wants this code to be > upgradeable in an independent way, he must distribute them as an > independent software package, not as part of the extension. The whole > code to consider as part of an extension, whatever the language, must > be kept in sync. And the best way to achieve this is to store it in a > single file. +1 — and the latter is what Benjamin was suggesting, albeit perhaps in not the most technologically sound way. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
