Breaking up the image

Daniel Vainsencher danielv at netvision.net.il
Tue Dec 10 21:47:46 UTC 2002


Ok. this wasn't very hard. WonderlandCameraMorph didn't get any
"interesting" categories as far as I can see, but it makes things
clearer for FileList, or Object.

The useful snippets are 
MultiModuleAnalyzer onPackageNamedStarting: '' <inspect it>
Gets you an mma that works on all packages in the system (all names
begin with an empty string.. :-)

Then (patience, this is very slow!)
(self classGraph adjacentsOf: #Object) 
	groupBy: [:e | self packageDefiningClassNamed: e] 
	having: [:s | true]
Will group the referenced classes by their defining package. This way
you can more easily ignore references that are ok (like FileList using
AlignmentMorph from Morphic-Basic is fine, but anything it uses from
System-Archives is suspect).

However running this I found a couple of small bugs, some due to using
an out of date version of PackageInfo. So anyone trying to replicate
should wait for the next release of SpT.

Daniel

Andreas Raab <andreas.raab at gmx.de> wrote:
> Hi Daniel,
> 
> This sounds as if we have some common ground. Good. Reading your
> message, I was concerned that people would want to have a class object
> with zero references to other classes regardless of the context - that I
> think would be very unwise.
> 
> About finding references to collaborators: How about adopting the DVS
> scheme?! E.g., it might be a more understandable measure to analyze the
> dependencies based on the categories the classes are in. This might
> (note: "might") help in identifying the internal collaborators. E.g.,
> I'd be interested to see for example how a "category dependency" looks
> for something like the WonderlandCameraMorph - I would expect it to be
> pretty much Kernel-* (some fundamental suff is used everywhere)
> Balloon3D-* and Morphic-* (due to the camera being the integration
> part). At this point you might be able to spot any "strange looking"
> categories. This of course assumes that classes are in "good" categories
> to begin with.
> 
> Cheers,
>   - Andreas
> 
> > -----Original Message-----
> > From: squeak-dev-admin at lists.squeakfoundation.org 
> > [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> > Behalf Of Daniel Vainsencher
> > Sent: Tuesday, December 10, 2002 7:50 PM
> > To: squeak-dev at lists.squeakfoundation.org
> > Subject: RE: Breaking up the image
> > 
> > 
> > Hi Andreas.
> > 
> > I of course don't mean that every single class in the list 
> > below should
> > have it's references removed. But it's a good shortlist to start
> > trawling for FileList-like objects.
> > 
> > Statistical measures are certainly an acceptable heuristic on how to
> > order your efforts, the question is only whether they're 
> > useful (classes
> > with lots of referenced classes are more likely than others to be
> > refactorable to remove those references). I think this measure is
> > useful, but we'll see.
> > 
> > About the first kind you describe, that's where the methods should
> > logically be in another package. In that case, I propose to 
> > move it to a
> > class extension, which would leave the functional link there, 
> > but reduce
> > the spaghetti factor, and potentially make things removable.
> > 
> > About the second kind you describe, of course we don't touch really
> > functional references. Making them artificial indirect is not 
> > likely to
> > help, as you say. I'd exclude them from the analysis, but I don't know
> > of a good method to do so. SpaghettiTracer is nice, but it's 
> > not *that*
> > smart.
> > 
> > To eventually look into the concrete context of each class and each
> > reference, as you propose, is absolutely essential. That's 
> > exactly what
> > I proposed, too, though I might not have made this clear...
> > 
> > As to whether the numeric data is useful at all - 
> > I know that that list makes me wonder what exactly Utilities and
> > SystemDictionary bind in, and whether all of those really 
> > belong in the
> > image (or maybe we could have Benchmarks package?), and whether
> > everything that ParagraphEditor knows is really essential, or 
> > maybe some
> > of those things (like WordNet) could be dynamically 
> > registered, and not
> > hard coded references.
> > 
> > And Stef seems somewhat surprised that for all of the FileList
> > refactoring, it still knows quite a bit of classes, like
> > FileContentsBrowser, and so he might have a look and read his own
> > comment on something he'd left there that could probably still be
> > removed. And maybe ChangeList deserves similar treatment.
> > 
> > Other people, that see different things, might be able to 
> > help in other
> > ways.
> > 
> > Of course, I too like the Top-Down approach, I think they're
> > complimentary, and I'm sure we'll do both, plenty.
> > 
> > Daniel
> > 
> > Andreas Raab <andreas.raab at gmx.de> wrote:
> > > Daniel,
> > > 
> > > I don't think that's a very good theory. You are taking statistical
> > > measures and apply meaning to them where you have to look at the
> > > concrete context. By and large I would argue that most of these
> > > references come from two different kinds.
> > > 
> > > One are references from methods where the method 
> > *logically* belongs to
> > > another package. Meaning that the reference to a class from 
> > this package
> > > is entirely reasonable and removing those would be 
> > obfuscating the fact
> > > that this method is not a part of the "Kernel-Object" 
> > aspect of objects.
> > > This certainly applies to many of the references in class Object and
> > > others in particular in any fundamental classes (like Morph).
> > > 
> > > Then, there are other references that come from a set of 
> > collaborators
> > > and which are entirely reasonable and perfectly logical. 
> > Would you be
> > > surprised to see references to (for example) the classes being
> > > responsible for graphics (color, fill style, border style, 
> > form, etc)
> > > being referenced from class Morph?! Certainly not - those are simply
> > > aspects which are used to describe the (composite) behavior of an
> > > animated graphical object.
> > > 
> > > Given the above, is there any meaningful interpretation of your
> > > results?! I argue not. Except from the fact that "Object 
> > references 63
> > > classes" there is no real information in this unless you 
> > start looking
> > > at where, how, and why a certain class is referenced.
> > > 
> > > And that's also why I like the "top-down" approach much 
> > more. Sure, I
> > > could go in and remove (for example) the reference to 
> > "TestTMethod" from
> > > Object>>primitive:parameters:receiver:. I might for example 
> > solve this
> > > problem by saying "ClassRegistry at: #TestTMethod" or (shorter)
> > > "Smalltalk at: #TestTMethod". But what have I done then?! I 
> > have just
> > > obfuscated the problem for someone who wants to work on 
> > VM-Removal. And
> > > really, that person should decide how to go about the 
> > problem, since it
> > > is understandable in the concrete context why the reference 
> > is there and
> > > why it may (or may not) be useful.
> > > 
> > > Of course, for some places the above does not apply (such 
> > as the file
> > > list) in particular if there is some general service that 
> > many clients
> > > (classes) want to subscribe to. Yet again, you have to look at the
> > > concrete context in order to figure out what is going on here. Just
> > > counting the number of references doesn't help you.
> > > 
> > > Cheers,
> > >   - Andreas
> > > 
> > > 
> > > > # of referenced classes -> #ClassNames
> > > >  127-> #Morph
> > > >  107-> #SystemDictionary
> > > >  85-> #PasteUpMorph
> > > >  77-> #Project
> > > >  73-> #Utilities
> > > >  63-> #Object
> > > >  55-> #ParagraphEditor
> > > >  50-> #ImageSegment #TheWorldMenu
> > > >  46-> #BookMorph
> > > >  44-> #FileList #ChangeList
> > > >  41-> #Preferences
> > > >  40-> #Form #ServerDirectory #SmartRefStream #ChangeSet
> > > >  39-> #Browser
> > > >  37-> #CodeHolder
> > > >  36-> #String #ChangeSorter #Debugger
> > > >  34-> #FileContentsBrowser
> > > >  33-> #FileList2
> > > >  32-> #AbstractSound 
> > > >  31-> #Behavior 
> > > >  30-> #SystemWindow
> > > >  29-> #MailMessage
> > > >  28-> #TextMorph #Flaps
> > > > 
> > > >
> >



More information about the Squeak-dev mailing list