At 16:42 10-08-01, Rasmus Lerdorf wrote:
> > Again, making a bad situation worse is not a good thing. I never said that
> > my code's perfect, and indeed there are some places where there's still
> > direct reference to auto-defined variable names, which is not a good
> > thing. Instead of making the situation worse though, when I face something
> > like this, I tend to try and improve it.
>
>What exactly have you improved? I agree that the macro duplication is
>bad. But having everything, including visible auto-defined variables be
>ZNED_ or zend_ doesn't make any sense to me.
>
>An extension now looks like this:
>
>::php_foo.h::
>
>extern zend_module_entry foo_module_entry;
>
>/* ZEND_FOO_API here? */
>#ifdef PHP_WIN32
>#define PHP_FOO_API __declspec(dllexport)
>#else
>#define PHP_FOO_API
>#endif
>
>#ifdef ZTS
>#include "TSRM.h"
>#endif
>
>ZEND_MINIT_FUNCTION(foo);
>ZEND_MSHUTDOWN_FUNCTION(foo);
>ZEND_RINIT_FUNCTION(foo);
>ZEND_RSHUTDOWN_FUNCTION(foo);
>ZEND_MINFO_FUNCTION(foo);
>
>ZEND_FUNCTION(my_func);
>ZEND_FUNCTION(your_func);
>
>ZEND_BEGIN_MODULE_GLOBALS(foo)
> int bar;
>ZEND_END_MODULE_GLOBALS(foo)
>
>#ifdef ZTS
>#define FOOG(v) TSRMG(foo_globals_id, zend_xmms_globals *, v)
>#else
>#define FOOG(v) (foo_globals.v)
>#endif
>
>
>::foo.c::
>
>ZEND_DECLARE_MODULE_GLOBALS(foo)
>
>function_entry foo_functions[] = {
> ZEND_FE(my_func, NULL)
> ZEND_FE(your_func, NULL)
>}
>
>zend_module_entry foo_module_entry = {
> "foo",
> foo_functions,
> ZEND_MINIT(foo),
> ZEMD_MSHUTDOWN(foo),
> ZEND_RINIT(foo),
> ZEND_RSHUTDOWN(foo),
> ZEND_MINFO(foo),
> STANDARD_MODULE_PROPERTIES
>};
>
>#ifdef COMPILE_DL_FOO
>ZEND_GET_MODULE(foo)
>#endif
>
>static void php_foo_init_globals(zend_foo_globals *foo_globals)
>{
> foo_globals->bar = 0;
>}
>
>ZEND_INI_BEGIN()
> STD_ZEND_INI_ENTRY("foo.bar", "0", ZEND_INI_ALL, OnUpdateInt, bar,
> zend_foo_globals, foo_globals)
>ZEND_INI_END()
>
>PHP_MINIT_FUNCTION(foo)
>{
> ZEND_INIT_MODULE_GLOBALS(foo, php_foo_init_globals, NULL);
> REGISTER_INI_ENTRIES();
> return SUCCESS;
>}
>
>ZEND_MSHUTDOWN_FUNCTION(foo)
>{
> UNREGISTER_INI_ENTRIES();
> return SUCCESS;
>}
>
>ZEND_MINFO_FUNCTION(foo)
>{
> php_info_print_table_start();
> php_info_print_table_header(2, "foo support", "enabled");
> php_info_print_table_end();
> DISPLAY_INI_ENTRIES();
>}
>
>ZEND_FUNCTION(my_func)
>{
> zval **foo_arg;
> int argc = ZEND_NUM_ARGS();
> int foo;
>
> if (argc > 1 || (argc && zend_get_parameters_ex(argc, &foo_arg) ==
> FAILURE)) {
> ZEND_WRONG_PARAM_COUNT();
> }
> convert_to_long_ex(foo_arg);
> foo = Z_LVAL_PP(foo_arg);
> REUTRN_LONG(foo);
>}
>
>
>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
--
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]
