On Tuesday, December 16, 2003, at 09:07 AM, Larry Wall wrote:
Seriously, I hope we can provide a framework in which you can screw around to your heart's content while modules are being compiled, and to a lesser extent after compilation. But we'll never get to a programming-in-the-large model if we can't limit most of the screwing around to the lexical scope currently being compiled, or at least to a known subset of the code. Modules that turn off optimization for all other modules are going to be about as popular as $&. So the general declaration should probably be something easy to see like:
use STRANGE_SEMANTICS_THAT_SLOW_EVERYONE_DOWN;
That will encourage people to be more specific about what they want to pessimize. Certainly, your fancy module should be encouraged to declare these things on behalf of its users if it can. I'm not suggesting that Lukian or Damianly modules force such declarations onto the users unless it's impossible for the module to know. And it seems to me that with sufficient control over the user's grammar, you can often get that information into your own fancy module somehow. Might take a few macros though, or analysis of the user's code at CHECK time (or maybe just before).
And in general, it's probably not necessary to declare all the new interfaces, but only those interfaces known at compile time that want to stay open. Any interfaces added at run time are probably assumed to be open. So in some cases you might find yourself deriving a single open class at compile time from which you can derive other open classes later.
Exactly, assuming I correctly understand. :-)
My own first instinct would be that the run-time extensibility of a particular interface/class would simply be a trait attached to that class... by default, classes don't get it. By limiting or not limiting the amount of runtime screwin' around you can do with the class, it is therefore able to control the level of optimization that calls to methods, etc., are given -- but specific to that particular interface/class, not to the module and certainly not to the program in general.
class Wombat is runtime_extensible { ... };
So everything is closed, except the specific classes which are not. Even when you are (to use an example from my own code) making runtime subclasses on-the-fly, you're almost always starting from some common base class. (And 'almost' is probably an unneeded qualifier, there. As is 'probably'.)
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 -- or, for that matter, simply subclass your original into a runtime_extensible class:
class Wombat { ... }; # Not runtime extensible
class MyWombat is Wombat
is runtime_extensible { ... }; # Runtime extensibleNow, 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. 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, such that if that class later falls into disuse, the optimizations silently reappear.
(At first glance, I am less sure of the need to have similar functionality for entire modules, as opposed to classes, but perhaps someone out there can come up with an example.)
MikeL
