Re: Re: cvs: php4 /ext/sablot php_sablot.h

> >Is this really what the goal is here? It seems like a contest to see how > >many times "Zend" can appear in the code. I think some of this stuff > >should be PHP_ or for things that really are engine related, perhaps > >ENGINE_ to at least pretend that this is a modular architecture where if > >someone was brave enough they could try to use the modularity and plug in > >another engine. > > There was no need to write this long Email just to make the simple point > that you want to make PHP modular in the other way, which it isn't and > never designed to be. Yes, PHP is completely dependant on the Zend engine, > and it's not supposed to be easy to plug in another scripting engine. When > Andi and I separate the engine from PHP it was with one goal - having the > ability to reuse it in applications other than PHP. I remember that you > immediately thought about it the other way around, but it's not any more > true today as it was then, and if you recall, I told you that right > away. An app built on a certain infrastructure is dependant on that > infrastructure, but not the other way around. > > >However, if everyone on php-dev thinks the above look to a PHP extension > >is just fine, I'll stop bickering. > > I'm +1 on that :) > > Zeev I do have to agree with Rasmus here. Yes, Zeev, PHP is completely dependant on its engine, but the macro names are not acting like a truly modular system. The analogy I come up with here is a hash table data structure. What if instead of having a neutral hash_function = weinberger_hash, you had weinberger_hash = whatever. This name convention really does not make much sence, becuase it implys that every hash function must be a weinberger algorythym. If you take a look at the ZEND_FUNCTION macro, this suggests to the module developer that he is writing a function for the ENGINE not the language. You are right that it is the engine's job to register functions, module names, etc. However that is the description of ANY engine, not just Zend. If you are to say that you are modular you MUST be able to clearly differiantiate between all the "modules" of the system, and yes any of those module should be capable of being replaced. I am not saying that anyone should even try to replace the engine, but I am saying there should be clear distinction between the components of PHP. If I could argue anything else, I would argue simple readibility. It should be clear to the PHP developers that they are using the systems API not one module that is a part of the system even if that module is the engine. -Jason > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net > For additional commands, e-mail: php-dev-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net >