On Thu, Sep 15, 2016 at 2:41 AM, Daniel Kochmański daniel@turtleware.eu wrote:
Additional adventage is a more uniform handling of the code (for instance in `find-system') and could pave a way for `monotonic-system' (from lack of better name atm) – system which only upgrades to the higher versions like ASDF does right now.
That would require a way of detecting the version before you load the system, for which ASDF has an ad hoc protocol that doesn't fit the normal system definition protocol. ASDF is a bit special because it has to be able to upgrade itself while it's running. Other systems don't usually have this constraint -- they can ask ASDF to upgrade them.
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.
[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.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I'd rather write programs that write programs than write programs — Dick Sites