Yeah, obviously with the source available anyone can refactor. I was aware of that. What I was thinking is that it would be better if there were a way of refactoring in a formal and well-defined manner.
See, right now the class library factoring scheme hasn't been given much airtime because the fact that the library does have standardized factors is pretty much just a construct of the ECMA [1]. So what I'm saying is that Rotor could become a platform where the factoring of the class library could become both explicit and enumerable. Right now, if I'm not mistaken, there is no way at runtime to determine a factor short of using reflection to examine every type in every library distributed as a part of that factor. There's also no good way to compare a custom factor to the ECMA standard ones. In short, there's nothing equivalent to interfaces for library factors. Now, this is a broad and not very well defined goal, I realize that; but in some ways it's intentionally that way-- it's more of a new direction Rotor could move rather than a tweak. But obviously that's not really that helpful, so I guess these would be my preliminary suggestions. Hopefully the suggestions will help make my larger meaning clearer. 1) I propose that we tag all classes with custom attributes specifying what class factor they belong to natively. In particular, of course, we follow the ECMA standard factors. 2) I propose that an XML specification be drafted for the defining class library factors. The specification would be sufficient to express which factors are completely included in the CLI distribution and perhaps the extent to which subsets of factors are available. The latter is optional, I think, because the point of a factor is to have a standard unit of library functionality. Maybe it also includes specifies assembly and/or module in which each type resides? 3) Associate factor information with the types at some level using attributes and an XML file following the specification outlined above. It's probable that this could simply be done at the assembly level. Native factor information can be accessed from reflecting the types themselves (since we already did #1). This will allow a person to specify to which custom factor, if any, the assembly belongs. (So, ArrayList from the Collections package might be bundled with the some items from the Common Datatypes package in a custom package.) 4) Since there may be many assemblies in the library, specify a single locus for getting this information at runtime (System.LibraryFactor or some such). This would allow access to a description of what the profile is of the installation of the CLI. So, Rotor would have a single library factor declaration which describes it, and whenever the library got refactored a name and description would be given to the distributed library as a whole [2]. Think of this as the glue which binds everything else together: it gives a name to itself, as well as enumerating each factor within it. 5) Do whatever else remains to make refactoring as simple as possible within the Rotor libraries-- stuff like having a single type per file, etc. I think this is mostly done, but in this step I'm covering my tracks for the things I haven't thought of yet. ;) I'm sorry these ideas are a bit jumbled. I understand the overall goal better than I understand the steps that need to be taken to get there. But hopefully you can at least see the kind of thing I'm talking about. How this relates to the game engine is in the fact that for some purposes you want to have a minimum memory footprint (when the DLLs are loaded at run time), a minimum hard disk footprint, minimum download time, etc. This can be paramount for small devices or embedded programming. It's not feasible now, but imagine Rotor on a modest cell phone (not Stinger or something), or even Rotor for Smart Cards. The point is that there's no good way to manage and relate library factorings right now, but custom factors have a lot of benefits when you get out of the realm in which the Microsoft CLR exists. There are a lot of reasons out there why it's not desireable to install the entirety of the feature set that is available. I don't know, maybe this just isn't a useful idea. It just seemed that way to me because, as CLI implementations grow in number, having a standard way of describing and working with different refactorings might be a good idea. If I'm wrong, feel free to tell me. [1] That is to say, try searching for information on the library factors in the .Net framework documentation. As far as I can see, it only exists in one or two PPT presentations and in the ECMA specification here (http://msdn.microsoft.com/net/ecma/part_4_Library.pdf). I can't imagine most people have any awareness of them. [2] Note that I'm talking about platform library distributions here, not applications. -----Original Message----- From: Discussion of the Rotor Shared Source CLI implementation [mailto:[EMAIL PROTECTED]] On Behalf Of David Stutz Sent: Monday, April 15, 2002 10:48 AM To: [EMAIL PROTECTED] Subject: Re: [DOTNET-ROTOR] Custom-factored class libraries (WAS: RE: [DOTNET-ROTOR] Rotor as a game scripting engine) "... 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?
