3 ms·
What happens is well specified, see [1] and more specifically [2]. I don't understand where packages even enter the picture though. Symbols/packages and method
by jorams 10y ago
What happens is well specified, see [1] and more specifically [2].
I don't understand where packages even enter the picture though. Symbols/packages and method dispatch are entirely separate concepts that are hardly related. You certainly won't get any weird errors from one in relation to the other. Furthermore, same-named symbols in different packages are just different symbols. The fact that their name is the same is irrelevant.
[1]: http://www.lispworks.com/documentation/HyperSpec/Body/07_ff.htm http://www.lispworks.com/documentation/HyperSpec/Body/07_ff....
[2]: http://www.lispworks.com/documentation/HyperSpec/Body/07_ffab.htm http://www.lispworks.com/documentation/HyperSpec/Body/07_ffa...
- kazinator 10y ago> What happens is well specified Nobody said it wasn't. > Symbols/packages and method dispatch are entirely separate concepts They are examples of different domains which have referential ambiguities. The object system resolves them. For instance, given (defclass base (d1 d2 ..) ...), base is considered slightly more of a d1 than a d2 in situations where this causes an ambiguity. The tie is resolved and life moves on. Multiple package use is also a kind of "inheritance", yet it blows up in your face when there are ambiguities caused by clashes (which "FOO" symbol do you want? The one from package "A" or "B"?) All these behaviors are specified, but according to different philosophy: just resolve things with a documented tie breaker, versus diagnose the situation. If it's OK for base to be considered slighly more of a d1 than a d2, why isn't it OK for, say, a later package use to just shadow an earlier one?