Quoting Benjamin Eberlei : > > 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.
Quoting Pierre : > 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. Quoting myself : >>> What I don't like is the fact to execute PHP code automatically at every >>> RINIT. I prefer to let the extension free to load its PHP code when its >>> logic decides it is needed. We are all talking about PHP scripts but with very different usages : - Pierre is talking about 'glue code'. From what I understand, this code is used directly from userspace but optional, and the final user can decide to use alternate code. So, it is legitimate that usage of this code is under the control of the final user and not to bundle it in the extension library. - Benjamin is talking about user-exposed essential extension classes. These MUST be defined at each request start or the extension loses part, if not all, of its API. His pov is legitimate too. The only prevention I would have is the overall impact on performance but, if the final user accepts it knowingly, why not ? - My use case is slightly more complex. My PHP contains pure 'back-end' features. This code is used exclusively from the extension C code and does not expose anything to userspace. To explain my use case to Benjamin, here is an example from the PHK extension : PHK is a package system. It distributes a virtual file tree. When I need to stat or read a virtual file, the C code first looks if the required data is present in a cache. If not, it loads the appropriate PHP code and calls it to retrieve the data from the package file. This PHP code is long, complex, and deals with many cases and options (virtual file tree, compression, package metadata...). Then, the C code caches the returned data. The next time the same resource is requested, it is retrieved from the cache WITHOUT having to load and execute the PHP code. The C code can decide when PHP code needs to be loaded because it is the only 'user' for this code (pure back-end). I can implement the complex code in PHP because it is behind a cache, but it is essential, for performance reasons, that this code is not loaded when everything I need is in cache. I'd prefer to embed my PHP code in the extension library because I definitely need to keep both codes in sync, and keeping them physically together is, IMHO, the easiest way to ensure this. Today, the runtime PHP code is stored in the package itself. It allows to make the extension optional, but with BC issues I wouldn't have if both codes were stored together. So, IMO, all 3 usages are legitimate but each of us has something different in mind. The solution for Pierre's needs is in build/deployment tools and ,maybe, a pair of C macros to define standard paths (I proposed one, what do you think about it ?). Benjamin and I would make full use of a generic, easy-to-use mechanism to embed plain files (not only PHP scripts, any data can fit) in an extension library. Then the extension developer decides what it loads at each request start. I'll try to build a prototype for this. Cheers François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
