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
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
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
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
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:
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, whichLet 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