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@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@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Daniel Vainsencher Sent: Tuesday, December 10, 2002 7:50 PM To: squeak-dev@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@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
squeak-dev@lists.squeakfoundation.org