On June 28, 2019 6:49:49 PM GMT+02:00, Benjamin Morel
<benjamin.mo...@gmail.com> wrote:
>
>> or unload the class once
>> it's not needed anymore (which is hard to detect with reflection and
>> other mechanisms which aren't bound to an instance's zval and also
>not
>> cheap)
>
>AFAIK, unloading a class is not possible from userland, I guess you're
>talking about detecting this in PHP itself?
Correct.
>Anyway, that's an edge case, I found a workaround which is to keep a
>cache
>of freshly created objects, indexed by interface name(s).
>Anytime I request a combination of types that's already been handled in
>the
>past, I return a clone of the cached object.
>
>Even though the possible combinations of types are huge and impossible
>to
>predict in advance, there are never more than a handful of such
>combinations used in a single document, and I'd be surprised if there
>are
>actually that many combinations actually used in the wild. So this
>should
>hardly be a problem.
This is going to be off-topic for his list: you could rethink your approach.
Maybe you can generate the classes only on demand (if you can derive the
information from a class name an evil way is `function __autoload($classname) {
/* figure out what is needed */ eval("class $classname { ...}")}` ...
absolutely evil, but hides the machinery) or you could rethink whether you
really need distinct classes or whether a single type with accessor routines
(either some custom or __call/__set/__get) isn't sufficient. Or something else
...
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
