[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Date: Tue, 19 Dec 89 13:51:30 EST
As I understand it from the documentation, we're supposed to use
(sys:record-source-file-name <name> <class> t) to avoid redefinition
errors from the compiler. I.e., we stuff this in when we're
redefining <name> in a different file from its first definition, and
we KNOW we're doing it, and we WANT to do it, without having to
interrupt the load process and say that we KNOW we're doing it, and we
WANT to do it.
We are supposed to do this INSTEAD OF using remprop on <name>.
However, what's NOT clear is where we're supposed to put the call to
this function. I've been putting it immediately before the
redefinition of the function. This does work, it removes the
offending error message. But it replaces it with a distracting and
confusing (for anyone who doesn't know what's going on) warning that I
am defining <name> twice in the second file.
Can anyone tell me what I'm doing wrong? Is there a way to use this
function properly, or should I go back to breaking the rules with
It goes before the new definition. I think the (undocumented) function
SI:ALLOW-REDEFINITION is a better way of doing this. Locally we have what
I think is still better: SI:ALLOW-REDEFINITION-BUT-CHECK-SOURCE which takes
args of the expected source file and version. If the function (flavor,...)
comes from that file, you won't get a redefinition warning. But if it
comes from somewhere else, you do. I use that for maintaining our mods
to Symbolics's code. When we change releases, all of our modified functions
get redefinition warnings until I go back and confirm that Symbolics's
source hasn't changed (and then I update my source).
I also think this would be a good idea for patch files to use this...
The idea for this doesn't originate with me. I got it from Rich Cohen