At 16:01 10-08-01, Rasmus Lerdorf wrote:
> > >php_sablot.h has:
> > >
> > >typedef struct _php_sablot_globals {
> > > zval *errorHandler;
> > > php_sablot_error *errors;
> > > php_sablot_error errors_start;
> > > char *output_transform_file; /* For output transformations */
> > > int last_errno; /* Global last_errno, if no handle is
> > > found */
> > > SablotHandle processor;
> > >} php_sablot_globals
> > >
> > >And now it won't build.
> >
> > It's a module interfacing with the engine. If it used the
> > BEGIN_MODULE_GLOBALS etc. macros, it'd build fine - I'll fix it.
>
>This stuff is more the interface with the thread-safe resource manager.
>These are not zend globals. They are extension globals.
>
> > Making a bad situation worse is simply not a good idea, that's why. PHP
> > extensions are really zend_module_entry's - the PHP macros are replicas of
> > the engine macros, which is a bad situation. Removing them was on my
> > TODO list on low prio, but I took the few minutes to do that now.
>
>I don't think this is a good trend. More and more stuff is being pulled
>into the engine. We are losing the clean distinction here.
Hmm? You might have lost track of it - but the clear distinction is
there. The fact you copied&pasted macros from the engine into php.h should
have given you the indication that you're doing something wrong... Nothing
was 'pulled' (well, except for some macro someone added to the wrong place,
php.h) - the replicas in php.h were simply removed.
Function modules are data structures that the engine defines, manipulates
and activates. Their definition are direct derivatives of the engine's
data structures. The macros that help build them are engine macros.
The fact we had a 2nd set in php.h was bogus.
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]
