Classes as Packages (was: Harvesting infrastructure)

Andreas.Raab at gmx.de Andreas.Raab at gmx.de
Sun Nov 17 23:55:17 UTC 2002


> 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. Still
I can see the usefulness for the interim period of refactoring and just a
general santity check (e.g., if you refer to a selector from a foreign package
this package should be in the transitive dependency chain).

> I've been thinking of writing a tool for automatically carving
> out the image that uses a greedy algorithm based on this - for each method
> that depends on a package, would it increase or decrease the number of
> external references by pulling the method into the package?  After a
> number of iterations, my guess is that you'd end up with a fairly good
> definition of the package (this is similar to what Anthony was describing,
> but I believe the final lines need to be drawn by humans, not
> algorithms - there's extra semantic content we can add through
> categorization that automated dependencies cannot).

I'd say give the information to the human to begin with. The process will in
almost all cases not converge (I tried it) trivially and if you get across a
certain point you'll end up with everything. The critical point is usually
easy to detect for humans but not automatically.

Cheers,
  - Andreas

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!




More information about the Squeak-dev mailing list