Faré wrote:
But I can speak to the fact that code that quietly goes away and does something unexpected or, worse, quietly does not do something expected, is very difficult to debug.
Indeed, the problem here is not that the breakage was invisible; the problem is that, upon seeing the breakage, the author (you in this case) had trouble tracing down the breakage to its root cause.
Let me clarify, the breakage WAS close to invisible.
The code that came through the allegedly successful compilation simply didn't function.
There was no error message that I could track back, because some code that should have been translated -- not COMPILED, but TRANSLATED, so that when the code wasn't translated, ASDF simply went away and reloaded the obsolete versions of the code.
There was NO ASDF breakage.
The only way to figure out what went wrong, well downstream, was to know that one had to look at the output of TRAVERSE to see that an operation we expected wasn't happening.
The breakage was WAY downstream, when odd things happened as a result of loading old versions of code.
So that's as close as you get to "invisible" without walking into the territory of "not a bug at all"!
You're right that maybe we could have at the end of each file a check for new subclasses of OPERATION, and a warning if an unknown one was >
found.
It is probably more portable to use the MOP to walk all defined subclasses than to intercept their definition as it happens.
That might be nice, but when would we run this check? After loading each new system? That seems a lot harder than running a check when a new OPERATION subclass is instantiated (as Pascal's suggestion).
[I am quite concerned about this because I am 95% sure that we have other systems like this out there that are just waiting to bite me. We have lots of systems that interact with outside software in ways that require ASDF to initiate, e.g., some make operations, something to build some Java code, starting up a server, etc.]
Cheers, r