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

From: Date: Sat, 11 Aug 2001 00:40:08 +0000
Subject: Re: cvs: php4 /ext/sablot sablot.c
References: 1 2 3 4 5 6  Groups: php.cvs 
Request: Send a blank email to php-cvs+get-6725@lists.php.net to get a copy of this message
Because the combination of the engine, the huge set of modules, the SAPI interface gives something which is a bigger than the sum of its parts - and that's PHP. It doesn't mean that we should make-belief as to what role the engine plays in PHP - it is 80% of the infrastructure, SAPI and TSRM are the other 20%, and on top of that, there's some glue code, and a huge set of modules. That's PHP. Zeev At 22:11 10-08-01, Jason Greene wrote:
If the extensions, data types, functions are all in the engine.... then what exactly is PHP... just a SAPI layer..... then why not call it zend-sapi...... -Jason ----- Original Message ----- From: "Thies C. Arntzen" <thies@thieso.net> To: "Zeev Suraski" <zeev@zend.com> Cc: "Thies C. Arntzen" <thies@thieso.net>; <php-cvs@lists.php.net> Sent: Friday, August 10, 2001 12:47 PM Subject: Re: [PHP-CVS] 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/
-- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, e-mail: php-cvs-unsubscribe@lists.php.net For additional commands, e-mail: php-cvs-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net
-- Zeev Suraski <zeev@zend.com> CTO & co-founder, Zend Technologies Ltd. http://www.zend.com/

« previous php.cvs (#6725) next »