> 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?
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?