Breaking up the image

Daniel Vainsencher danielv at netvision.net.il
Tue Dec 10 18:49:31 UTC 2002


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