Everything

php

[PATCH] Resubmitted for review

php.internals

Robert Silva

21 years ago

This patch allows php extension authors to declare constants on internal
objects. This pretty much just duplicates the zend_declare_property_*
functions but for constants. Currently there is no way for C level class
authors to declare constants on their objects since the engine has to
allocate space for them.

Bob Silva

Andi Gutmans

21 years ago

We were discussing adding a per class (zend_class_entry *) callback for
constants. It might make sense to allow that and if the callback is NULL
then try the constant's hash in zend_class_entry.
That should solve all cases, right?

Andi

At 11:54 PM 10/11/2004 -0700, Robert Silva wrote:

Marcus Börger

21 years ago

Hello Andi,

Tuesday, October 12, 2004, 11:43:11 PM, you wrote:

> We were discussing adding a per class (zend_class_entry *) callback for
> constants. It might make sense to allow that and if the callback is NULL
> then try the constant's hash in zend_class_entry.
> That should solve all cases, right?

Andi still the patch is a good extension to the engine API and i think
we should add it. Why should every programmer that wants constants add
constant handlers just to add some basic constants? I see the handlers
only to allow soem special cases, maybe to have array consts or whatever.

marcus

Andi Gutmans

21 years ago

At 12:34 AM 10/13/2004 +0200, Marcus Boerger wrote:

>Hello Andi,
>
>Tuesday, October 12, 2004, 11:43:11 PM, you wrote:
>
> > We were discussing adding a per class (zend_class_entry *) callback for
> > constants. It might make sense to allow that and if the callback is NULL
> > then try the constant's hash in zend_class_entry.
> > That should solve all cases, right?
>
>Andi still the patch is a good extension to the engine API and i think
>we should add it. Why should every programmer that wants constants add
>constant handlers just to add some basic constants? I see the handlers
>only to allow soem special cases, maybe to have array consts or whatever.

That's exactly what I said in my email. Allow to levels. The callback level
and the hash level which Robert implemented.
Re-read what I wrote :)

Andi

Marcus Börger

21 years ago

Hello Andi,

Wednesday, October 13, 2004, 12:37:36 AM, you wrote:

> At 12:34 AM 10/13/2004 +0200, Marcus Boerger wrote:
>>Hello Andi,
>>
>>Tuesday, October 12, 2004, 11:43:11 PM, you wrote:
>>
>> > We were discussing adding a per class (zend_class_entry *) callback for
>> > constants. It might make sense to allow that and if the callback is NULL
>> > then try the constant's hash in zend_class_entry.
>> > That should solve all cases, right?
>>
>>Andi still the patch is a good extension to the engine API and i think
>>we should add it. Why should every programmer that wants constants add
>>constant handlers just to add some basic constants? I see the handlers
>>only to allow soem special cases, maybe to have array consts or whatever.

> That's exactly what I said in my email. Allow to levels. The callback level
> and the hash level which Robert implemented.
> Re-read what I wrote :)

Ah! Sorry i got you wrong in that i thought you wanted the hash thingy only
for user declared consts.

narcus

Andi Gutmans

21 years ago

Hi Robert,

If I remember correctly, we came to the conclusion a while ago, that unless
we make some big changes (which I'm not quite sure yet how far reaching
they would be), then we could not malloc() constants. You would really need
to emalloc()/efree() them on each request because the engine could connect
to these malloced()'ed variables and all hell would break loose. Also we do
a zval_update_constant() today in order to initialize constants with
constants just before they are being used the first time.

What this basically means that you'd initialize and free these constants in
RINIT()/RSHUTDOWN(). Not too sexy but looking at how much this is needed
it's not too bad.

Andi

At 11:54 PM 10/11/2004 -0700, Robert Silva wrote:

Robert Silva

21 years ago

Don't completely follow you since I don't have the required knowledge of the
Zend Engine (yet). The problem that I ran into (I think) was that
destroy_zend_class gets called before rshutdown and it was releasing the
entries in the constants_table before I had a chance to do it, hence the
patch which lets the engine manage them.

Sorry if I'm totally lost, but I don't understand why class constants would
be handled any differently than properties which are created and destroyed
with the class. (Which, on the surface at least, appears to work, they get
released during destroy_zend_class).

Bob Silva



-----Original Message-----
From: Andi Gutmans [mailto:andi@zend.com]
Sent: Thursday, October 14, 2004 5:14 PM
To: Robert Silva; internals@lists.php.net
Subject: Re: [PHP-DEV] [PATCH] Resubmitted for review

Hi Robert,

If I remember correctly, we came to the conclusion a while ago, that unless
we make some big changes (which I'm not quite sure yet how far reaching
they would be), then we could not malloc() constants. You would really need
to emalloc()/efree() them on each request because the engine could connect
to these malloced()'ed variables and all hell would break loose. Also we do
a zval_update_constant() today in order to initialize constants with
constants just before they are being used the first time.

What this basically means that you'd initialize and free these constants in
RINIT()/RSHUTDOWN(). Not too sexy but looking at how much this is needed
it's not too bad.

Andi

At 11:54 PM 10/11/2004 -0700, Robert Silva wrote:

>This patch allows php extension authors to declare constants on internal
>objects. This pretty much just duplicates the zend_declare_property_*
>functions but for constants. Currently there is no way for C level class
>authors to declare constants on their objects since the engine has to
>allocate space for them.
>
>Bob Silva
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php