Let me stress a couple of things:
#1 I dont use closures anymore because I cant risk the memory consumption issue. I may be able to get an idea if a closure is safe within my code but I cannot get an idea of how a plugin can make calls into my code. Maybe if I knew the darned thing got garbage collected when the instance it was tied to was no longer in reach, I would consider using it again.
#2 I like closures. I like them alot. There are many times when using a closure is the right solution. But you cant use them if they damage your memory like they do. I wouldn't be asking if 'closures were improved in a1' if I didnt like the construct. I like coding with them, I dont like what they do to the runtime. As it is, the results of the construct makes them practically useless.
to be honest, I dont care if the class has to have a unique identity yet contain duplicated behavior. I think you might be able to cache the original and reuse it if you follow some rules:
1. Defer creating a unique class until the class is modified. If a class is not modified than you never pay the price of recreating the class over and over. When modified, clone the class and perform the modification on the clone. The original and all the other almost perfectly similar classes remain unmodified. Then you can have your class factories and modify them to your hearts content.
2. Create the appearance of the class being unique... at its heart its the same.
the end result for most normal closure usage would not be needlessly creating, conceivably, 1000s upon 1000s of classes.... you can get away with one.
Kent Johnson <email@example.com> wrote:
You still haven't given any reason why you can't just pull the class def out of the function and fix your problem. The main reason to put the class in the fn is because you *want* a different class each time (you could do it for scoping reasons also). If you dislike it so, do something else.