Classes as Packages (was: Harvesting infrastructure)

Anthony Hannan ajh18 at cornell.edu
Mon Nov 18 01:26:25 UTC 2002


Andreas.Raab at gmx.de wrote:
> What's needed to figure out dependencies automatically is to give every method
> and global variable binding a dedicated "home" that describes where it is
> defined. This is crucial. Then, you can trivially figure out the prerequisites
> for a class by going through the imported bindings (literals, superclass, and
> pool vars) and see what is referenced where.

> > The recently released version of PackageInfo does pretty much this, in
> > reverse - PackageInfo>>browseExternalReferences will bring up a MessageSet
> > of all methods that depend on that package (based on referencing either
> > class literals of that package, or selectors implemented only by that
> > package). 
> 
> 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.

That is clever insight.  But what if package A calls a new Object method
defined in package B but does not reference anything else in package B, nor
does any other prerequisite packages.  How will you automatically detect that
package B is a prerequisite of package A.  Or is this not well-formed.

If you include the new method because its implemented in Object which is
included, then how do you exclude other class extension methods that when
brought in will bring in another package that you don't want.

I took a different approach of associating selectors with abstract
classes and including them as prerequisites if sent, but I don't include
superclasses.  A class and all subclasses down to explicitly referenced
concrete classes will be included only if some class sends one of its
selectors.  Not including superclasses was important for excluding extra
class-extension behaviors (added as superclasses - using multiple
inheritance - for other packages).  But if your not including methods
from outside packages either, we end up with pretty much the same result.

Avi Bryant <avi at beta4.com> wrote:
> Once everyone starts using PackageInfo's conventions (or some equivalent),
> dependency analysis will become a lot simpler...

Agreed, if we want to go to multiple inheritance someday it would be easy to
find these class extensions and put them in separate behaviors.

Cheers,
Anthony



More information about the Squeak-dev mailing list