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]
