Faré writes:
Rationale for registering a new system is as follows: preloaded-systems and immutable-systems are separate kind of system treated differently in the code and have a separate class, because of their very nature.
I don't buy that. Immutable systems could be made thus by adding a slot immutable-p to all systems. The reason we're using a table instead is because we want fast access to the list of only those systems that are immutable without groveling a large list of all the defined systems, that most usually aren't. At which point we don't need the slot.
I believe it would be improvement upon current design (explicit consulting with separate hash tables, special cases in the code, calling something a xxx-system while it's in fact xxx-flagged-system). I'm not insisting on that change, since the issue which made me work on that is (mostly, if not entirely) solved.
Either way I think that at least removing immutability flag from the system should be abstracted by a protocol (i.e `deregister-immutable-system' or something of this kind) instead of calling remhash. This will make such desing changes possible in the future if someone will find it important without breaking the backward compatibility.
[To preserve the build information] an instance could store the original system in a slot, which gets registered during the call to `deregister-immutable-system'.
If you preserve the build information, why change the system object at all?
You seem all set on defining new classes for preloaded and immutable systems, but don't explain why it's useful, just offer workaround for all the detrimental effects of the design.
You said it, it's desirable to not carry build information exposed in non-development host, but getting rid of the data isn't much so. Such solution keeps both qualities.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I'd rather write programs that write programs than write programs — Dick Sites
Regards, Daniel