Re: Memory leak in eval()'d code

On June 28, 2019 6:49:49 PM GMT+02:00, Benjamin Morel <benjamin.morel@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