[V3dot10] needed tool

Milan Zimmermann milan.zimmermann at sympatico.ca
Sat Jan 27 06:26:45 UTC 2007

On 2007 January 26 03:20, Göran Krampe wrote:
> Hi!
> > On 2007 January 25 05:32, Bert Freudenberg wrote:
> > Thanks. Back to Squeak for a sec, because all code (class, method) is now
> > separated to belong to exactly one Package, would it be possible (and
> > let's
> > assume first we are strongly typed in Squeak, so we know the receiver
> > always), to write a program which,  by looking at senders and
> Mmm, just nitpicking but Squeak is strongly typed, it just isn't
> statically type.

Yes, I really ment statically typed (ehm, after the fact), for the purpose of 
such tool (doing source code analyses) to be completely accurate, knowing 
types is what would be needed; but even without it, most message names being 
unique, accuracy should be sufficient.

> I know the terms are a bit vague in definition though. 
> > implementors,
> > would generate a "package dependency graph"? Am I missing something
> > substantial (I am sure I am :) ).
> >
> > Thanks Milan
> As most of the time someone has already "been there and done that":

Thanks, you are right. I will look at the paper and the code next week. It 
seems this discovers class dependencies, from which should be a path to 
Package dependencies.

>     http://map.squeak.org/packagebyname/mudpie
> Not sure though if MudPie actually analyzes senders/implementors, Daniel
> can surely describe it more (and you should be able to find plenty in
> squeak-dev archives).

There is also a paper references in the package, 
http://esug2003.esug.org/academic/1-vainsencher.pdf but it is no longer 
there, shall google.

> regards, Göran
> PS. I even toyed with the idea of just using global references analysis as
> a way to figure out dependencies in SM. It wouldn't surprise me if that
> would catch 90% of them, since most packages use unique class names and
> most users of a package needs to reference at least some of the classes in
> order to "use" it.

You mean just to look at places where classes are instantiated (or class 
methods are used), from the class name, derive the package , and that must be 
a "predecessor/prerequisity" of the class where that code was found? That 
could like you said give quite accurate picture with simpler code I guess.

I think I am getting off topic on 3.10 with this.

Thanks Milan
> _______________________________________________
> V3dot10 mailing list
> V3dot10 at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/v3dot10

More information about the V3dot10 mailing list