On Mon, 18 Nov 2002 Andreas.Raab at gmx.de wrote:

> The latter isn't even needed (though you have to think about this for a
> while). From the POV of your package it can only reference the classes it refers
> to explicity. This also implies that it can only create instances of those
> classes. If the selector is implemented by a class you don't refer to it means
> that you (locally) assume that class never has any instances and so the code
> is either never run (very likely) or has a bug (sending this selector to an
> object not implementing it). Then, there's the transitive dependencies through
> your prerequisites, one of of which may in fact refer the class/package
> implementing this selector. But since it's a prerequisite of yours you don't have
> to worry since it'll be loaded before you get in.
>
> So for a well-factored system there is no need to track the selectors.

Right.  But that's the key - what I'm interested in right now is finding
the methods that fall into the "never run" case, and assigning them to the
correct package (one in which they presumably are run), so that we do
indeed end up with a well-factored system.

Once everyone starts using PackageInfo's conventions (or some equivalent),
dependency analysis will become a lot simpler...