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

On Fri, Aug 10, 2001 at 04:58:25PM +0300, Zeev Suraski wrote: > 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. lets just rename PHP to Zend! thanx for listening:-( tc > > 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/ >