Re: cvs: php4 /ext/sablot sablot.c

Thies, You got it wrong. The engine provides services, on which modules are built. The data types, functions, etc. are all defined in the engine, using engine macros and names. PHP is one application that can be built on top of the engine, there are others. Obviously, the names to use are those of the engine, not PHP's. I'm changing the names so that they have different prefixes, but they'll all be defined in the engine, which is the right thing to do from a software development point of view. Zeev At 16:55 10-08-01, Thies C. Arntzen wrote:

On Fri, Aug 10, 2001 at 04:40:42PM +0300, Zeev Suraski wrote: At 16:30 10-08-01, Thies C. Arntzen wrote:

On Fri, Aug 10, 2001 at 01:04:59PM -0000, Zeev Suraski wrote:

zeev          Fri Aug 10 09:04:59 2001 EDT

Modified files:

    /php4/ext/sablot  sablot.c

Log: More build fixes Index: php4/ext/sablot/sablot.c diff -u php4/ext/sablot/sablot.c:1.50 php4/ext/sablot/sablot.c:1.51

--- php4/ext/sablot/sablot.c:1.50     Fri Aug 10 08:28:15 2001

+++ php4/ext/sablot/sablot.c Fri Aug 10 09:04:58 2001 @@ -209,7 +209,7 @@ ZEND_GET_MODULE(sablot) #endif -static void php_sablot_init_globals(php_sablot_globals *sablot_globals) +static void php_sablot_init_globals(zend_sablot_globals

*sablot_globals TSRMLS_DC)

{

      sablot_globals->processor             = NULL;
      sablot_globals->errors                = NULL;

@@ -222,7 +222,7 @@ PHP_MINIT_FUNCTION(sablot) { #ifdef ZTS

-     ts_allocate_id(&sablot_globals_id, sizeof(php_sablot_globals),

(ts_allocate_ctor)php_sablot_init_globals, NULL);

+     ts_allocate_id(&sablot_globals_id, sizeof(zend_sablot_globals),

(ts_allocate_ctor)php_sablot_init_globals, NULL); i'd really like to keep the extension function/variables etc in the php* namespace, i use completion in gdb quite often, and by mixing zend_ prefixed variables into php space it doesn't make this easier. i do not think there is any pressing reason to prefix php-extension globals with zend_ instead of php_. lets keep the namespaces separate!

Thies, Read my responses to Rasmus. The reason there was a mix was the redundant definitions in php.h. The reason for my fix was to eliminate this long-going mix. I don't see how it has any effect on gdb debugging, other than being more consistent (not having to look for two types of symbols, just one). As you may know, I also debug using gdb, more often than I care to... Does the fact that internal function implementations have the same prefix as the engine functions bother you? If that's the case, we can use a different prefix, but we should have just one set of macros either way.

    we're only talking namespaces here: yes, i'd like to have
    seperated namespaces for as many modular parts of php as we
    can have. this is INHO simply GoodDesign(tm).

    prefixing everything the same way makes prefixed completely
    unnecessary - which would be also an option:

    right now               your approach           another idea
    --------------------------------------------------------------
    php_sablot_globals      zend_sablot_globals     sablot_globals
    zend_hash_update        zend_hash_update        hash_update

    1 makes sense (everything in Zend/ is prefixed zend_
    everything in TSRM/ tsrm_ and the rest is prefixed php_).

    option 2 is a waste of characters which doesn't gain us
    anything except namespace protection, but then we could as
    well prefix everything with thies_;-)

    option 3 seems the clearest from an SE view of things, but
    that would "undermine" the seperation of the Engine and PHP.

    i personally like 3 the most - but for various reasons lets
    stick with 1.

    re,
    tc

-- Zeev Suraski <zeev@zend.com> CTO & co-founder, Zend Technologies Ltd. http://www.zend.com/