Breaking up the image
andreas.raab at gmx.de
Tue Dec 10 20:18:03 UTC 2002
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.
> -----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*
> 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
> Of course, I too like the Top-Down approach, I think they're
> complimentary, and I'm sure we'll do both, plenty.
> 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
> > 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