> >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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
