RFC: internal class' static properties

php.internals

Michael Wallner

21 years ago
As already mentioned earlier, there does not seem to be any extension or core code using static properties for internal classes. I'd like to request a change in their behaviour/implementation. Currently static properties of internal classes are allocated persitently which limits their usage and has odd sideaffects. AFAICS they are declared at MINIT and initialized once, also at MINIT. Now, if they become modified (running as a module) they'll "leak" from one request to another. Therefore I'd suggest changing that so that they'll be initialized and destructed for each request, which means that there will need to be some form of hooks, which AFAICS also allows to have streams or arrays (i.e. complex types) as static properties just like in userland. PS: It seems that there's class constant API missing too. Regards,
-- Michael - < mike(@)php.net >

Michael Wallner

21 years ago
I wrote:
> Therefore I'd suggest changing that so that they'll be > initialized and destructed for each request, which means > that there will need to be some form of hooks, which
Let me change that part... :) There's no need for any "hooks" as there's already RINIT() and RSHUTDOWN(), so I guess all I'm proposing is not handling static properties of internal classes persitently. Regards,
-- Michael - < mike(@)php.net >

Marcus Börger

21 years ago
Hello Michael, Tuesday, August 9, 2005, 2:19:25 PM, you wrote:
> I wrote:
>> Therefore I'd suggest changing that so that they'll be >> initialized and destructed for each request, which means >> that there will need to be some form of hooks, which
> Let me change that part... :)
> There's no need for any "hooks" as there's already > RINIT() and RSHUTDOWN(), so I guess all I'm proposing > is not handling static properties of internal classes > persitently.
class consts should be easy and we two times had a patch for that. And i definitively ask to support that since otherwise we flood our namespace, see pdo, spl and the amount of defines there. With a peep to pecl i see tons of more consts (especially in http). regarding static props the solution is to define another hash table in the class_entry that holdes the initial values for the static variables. During minit these would be copied to the used hash table, done. But even though the solution is pretty easy i do not know if we really want to support that. We have default properties and all that stuff already. Can't we simply check if default values for static properties wouldn't do the job and if there is something missing in that? Andi? Best regards, Marcus

Michael Wallner

21 years ago
Marcus Boerger schrieb:
> regarding static props the solution is to define another hash table > in the class_entry that holdes the initial values for the static > variables. During minit these would be copied to the used hash table, > done. But even though the solution is pretty easy i do not know if we > really want to support that. We have default properties and all that > stuff already.
I attached a patch, which fixes the static property issue for me, though I didn't test as a webserver module yet.
> Can't we simply check if default values for static > properties wouldn't do the job and if there is something missing in > that?
Huh? I even think that zend_std_get_static_property() is not enough... This forces you to have real zvals for your static properties. Maybe a minor issue (but still an issue :)
> class consts should be easy and we two times had a patch for that. > And i definitively ask to support that since otherwise we flood our > namespace, see pdo, spl and the amount of defines there. With a peep > to pecl i see tons of more consts (especially in http).
The patch also contains API for class constants, tough valgrind reports some odd errors about the constants_table (among "some" others...) Anyway, I'd be glad if the patch could be reviewed, fixed (as it's most probably not totally accurate) and -even partially- applied. Thanks, Michael

Andi Gutmans

21 years ago
Hi Michael, I agree that this might be the right way to resolve the current issues. I mentioned it to Marcus at OSCON. Andi At 02:19 PM 8/9/2005 +0200, Michael Wallner wrote: