German

Thank you for your work and for raising this important question.

"German Morales" <germanmorales at delta-sys.com> wrote:
> Hi everybody,
> 
> On the Swiki page of the Morph Cleaning Project
> (http://minnow.cc.gatech.edu/squeak/3005), Daniel Vainsencher wrote:
> 
> "one of the things that makes Morph the hub of a big tangle, is the fact
> that it references classes it shouldn't know, for example, alot of it's
> own subclasses".
> 
> 
> To see how much Morph refereced their own subclasses, I wrote the
> following script (enhancements welcome):
> 
> 
> Transcript show: 'Classes referenced by their Superclasses'; cr.
> 
> Morph allSubclasses do: [:eachClass |
>  allCalls _ Smalltalk allCallsOn:
>    (Smalltalk associationAt: eachClass theNonMetaClass name).
>  allReferencingClasses _ (allCalls collect:
>    [:each | Smalltalk classNamed: each classSymbol]
>    ) asSet.
>  allReferencingSuperclasses _ allReferencingClasses select:
>    [:each | eachClass allSuperclasses includes: each].
>  allReferencingSuperclasses do:
>    [:each | Transcript show: eachClass; show: ' --> '; show: each; cr].
> ].
> 
> 
> The result is this BIG list:
> 
> Classes referenced by their Superclasses
> TTSampleStringMorph --> TTSampleFontMorph
> ObjectPropertiesMorph --> Morph
> StackMorph --> Morph
> Viewer --> Morph
> LineMorph --> BorderedMorph
> LineMorph --> PolygonMorph
> StringMorph --> Object
> StringMorph --> Morph
> BalloonMorph --> Morph
> SketchEditorMorph --> Morph
> StandardViewer --> Object
> StandardViewer --> Morph
> SimpleButtonMorph --> Morph
> ImageMorph --> Morph
> SyntaxMorph --> Morph
> MovieClipEndMorph --> MovieClipStartMorph
> SystemWindow --> Morph
> EToyGateKeeperMorph --> EToyCommunicatorMorph
> ListViewLine --> Morph
> ColorPickerMorph --> Morph
> ScriptEditorMorph --> Morph
> TileMorph --> Object
> AlignmentMorph --> Morph
> HandleMorph --> Morph
> HandleMorph --> BorderedMorph
> MovieMorph --> Morph
> SketchMorph --> Morph
> TextPlusPasteUpMorph --> Morph
> TrashCanMorph --> Morph
> TwoWayScrollPane --> Morph
> URLMorph --> Morph
> PasteUpMorph --> Morph
> ButtonPropertiesMorph --> Morph
> CollapsedMorph --> Morph
> PhraseTileMorph --> Morph
> GraphicalMenu --> Morph
> TransformationMorph --> Morph
> HandMorph --> Morph
> TextPropertiesMorph --> Morph
> IconicButton --> Morph
> BookMorph --> Morph
> MorphThumbnail --> Morph
> TextMorph --> Morph
> MenuMorph --> Object
> MenuMorph --> BorderedMorph
> MenuMorph --> Morph
> HaloMorph --> Morph
> MVCWiWPasteUpMorph --> Object
> MVCWiWPasteUpMorph --> Morph
> 
> 
> Now the question: Bug or Feature?
> 
> Is it OK for a Framework? I'd answer yes in general, but we should go
> through the list and analyse each case. As an example, try the same for
> Collection instead of Morph: you will get a long list too.
> 
> Waiting for comments...


I must admit that I have referred to subclasses from the superclass
sometimes in my designs. For example once I was writing a parser. The
superclass dealt with the stream and handed the stream to various
subclasses who read from the stream and returned the instantiated
object. However in that case a builder would have been fine as well and
later I changed the design by using a dictionary to look up thich class
to adress.

In the question above I think various cases and answers apply. That you
didn't get get an answer while people were heavily discussion font
issues (the same discussion as the year before and another year before)
indicates that this question is difficult.

For example the HaloMorph: I think it is ok that Morph refers to them. 
We have in Morph

haloClass
	"Answer the name of the desired kind of HaloMorph to launch on behalf
of the receiver"

	^ #HaloMorph

This usage is OK.


And we have just two methods in Morph which use HaloMorph at all. They
do 

   prospectiveHaloClass _ Smalltalk at: self haloClass ifAbsent:
[HaloMorph].

   prospectiveHaloClass _ Smalltalk at: self haloClass ifAbsent:
[HaloMorph].

Two times the same thing. The only case where this could apply is if
somebody overrides the method haloClass with an empty method body.

So in this case the proper solution probably would be

  prospectiveHaloClass _ Smalltalk at: self haloClass ifAbsent: [self
defaultHaloClass].

while 

defaultHaloClass
  ^ Smalltalk at: #HaloMorph



At the moment it seems one has too look at each case individually. Any
others to chime in?

Regards
Hannes