[V3dot10] needed tool
milan.zimmermann at sympatico.ca
Sat Jan 27 06:26:45 UTC 2007
On 2007 January 26 03:20, Göran Krampe wrote:
> > 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
> 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.
> V3dot10 mailing list
> V3dot10 at lists.squeakfoundation.org
More information about the V3dot10