Guys,
It's really simple, even trivial soft-dev issue, which is discussed in a
completely broken manner, because you pour politics into the picture.
The Zend Engine is the infrastructure of PHP. Until there's another
engine, which is nowhere at sight nor is there any good reason to have one,
PHP has one way dependency on the Zend engine, and is basically an app
built on top of it. As such, it uses its macros, data types and functions.
Duplicating the macros was bad. Period. There's no argument about it from
a soft-dev point of view. It's the basic rule of no-code-duplication. I
hope nobody disagrees with me on that one.
So, where should the macros reside? Let's see. They can either reside in
the app that uses them, or the infrastructure that defines their very
existence. That's not a very tough call in my book (Jason - you got it
pretty wrong with the 'so is any other scripting engine'; The Zend API, on
top of which PHP is built is very specific, and there's no other engine in
existence that implements any API which resembles it; PHP is already
tightly coupled with this infrastructure, long before I nuked the macro bloat).
Sascha's right, in the sense that if we were to abstract PHP to support
multiple engines, the API and the implementation of the API wouldn't have
been the same. In that case, PHP would have had some glue layer between
itself and whatever engine it was using. At the risk of encouraging Sascha
to write a new engine just to make a point, we aren't in a situation where
we need to abstract PHP for multiple engines, nor is there any good reason
for ever arriving to such a situation. We're not ASP with several
pluggable syntaxes.
Do PHP modules contain too many ZEND strings? Just as much as they should,
since in practice, they are Zend modules. We can still define PHP macros
to wrap the Zend ones for 'political' reasons, I personally think it's
childish, but it wouldn't be a first... The advantage to using the Zend
API macros directly is that the modules could be compiled outside the
context of PHP, and load into the engine in other apps that use this engine
in the future. This is just another example of why the basic soft-dev rule
of putting the infrastructure-derived macros in the infrastructure and not
in the application on top of it is correct.
Zeev
At 17:21 10-08-01, Jason Greene wrote:
> > >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]
> >
--
Zeev Suraski <[EMAIL PROTECTED]>
CTO & co-founder, Zend Technologies Ltd. http://www.zend.com/
--
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]
