"... that the Rotor code base lend itself to refactoring" is a very, very broad goal to propose. Unfocused refactoring is often an anathema to efficiency (although supporting a modular codebase for academic use is clearly useful).
Putting asided the obvious answers (that refactoring is *always* a possibility with a source code distribution!), I'd say that the lazy way that classes load and compile right now is actually very close to what you are asking for. Perhaps you are concerned with on-disk footprint? Or the size of the in-memory metatdata image? When you say "in a situation where a lot of efficiency is needed, you won't want to carry along any more information than is necessary," it sounds as though you are talking about bandwidth-constrained situations? More details would definitely help us to understand your questions and suggestions better. Thanks! -- David Stutz Dominic wrote: The solution, in my mind, is to create a custom class factor which has its own binary architecture and its own class inclusions. This is impossible with the MS .Net CLR, but it seems to me that it would be entirely viable with a codebase like Rotor. So after too-long a preamble, here're my questions: 1) Am I off base here? 2) Is there any way to make such a thing easily done using the Rotor code-base? 3) If this were formalized as one goal of the Rotor project (i.e. that the Rotor code base lend itself to refactoring), might that not give it a much wider, and more useful, application to other projects?
