On Tue, Dec 16, 2003 at 12:06:46PM -0800, Michael Lazzaro wrote: > As far as users of your class being able to specify that they want > something runtime-extensible, when your original module didn't call for > it, I don't see that as a problem, if they can just add the trait to > your class shortly after they C<use> the package containing it, if such > things are possible
I think it kind of hinges on the ability to undo optimizations. Just to restate things a bit to make sure I understand ... when perl compiles a class, it assumes it's closed and accordingly applies whatever optimizations it can unless it sees that the programmer explicitly asked otherwise. Those classes that are "closed" can be opened at run-time and the user pays the penalty then when they try to modify the class (and pays twice because of the compile-time optimizations that perl applied and are now undoing). But does everybody pay some penalty because of it? I hope not. Presumably we keep the source around for a reparse if necessary anyway? Or perhaps we have "unoptimized" bytecode laying around ready to be switched in for the optimized bytecode when necessary. > class Wombat { ... }; # Not runtime extensible > class MyWombat is Wombat > is runtime_extensible { ... }; # Runtime extensible > > Now, it might be that declaring MyWombat to be runtime_extensible > actually silently disables some compile-time optimizations not only for > it, but for all its superclasses/roles/etc., depending on how > intelligent and far reaching those optimizations may be. I hope not. > Not sure. > Still, the fact that you are _requesting_ that happen is specific to > the particular class that needs it -- and should be associated with > that class, Yep. > such that if that class later falls into disuse, the > optimizations silently reappear. That would be *some* trick! -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]