Whither Squeak?

Ralph Johnson johnson at cs.uiuc.edu
Sun May 21 07:07:02 UTC 2006

On 5/20/06, Daniel Vainsencher <danielv at techunix.technion.ac.il> wrote:
> Improving design:
> ------------------------------
> Cyclic dependencies (considering just
> compilation-time-obvious dependencies, like a method in one class
> refering to a parent) are rampant in Squeak (see references to Morph),
> making it difficult to decompose.

Classes are not modules.  A module will include methods added to other
classes.  So, it is possible for class A to refer to B and class B to
refer to A, but A and B are in different modules with no cycles.
Suppose class A is in module X, and it depends on module Y, which
contains class B.  Then the method in B that refers to A is actually
part of module X, even though most of B is in Y.

I don't know the example you are talking about, and it might very well
be an example of something that needs to be fixed.  But the fact that
Object has an "inspect" method doesn't mean that the entire GUI is in
the same module as Object.

This *does* make a system difficult to decompose because you can't
assume that you can just assign classes to modules and be done.  You
can make that assumption in languages that don't allow a module to add
a method to an existing class.  On the other hand, the increased
flexibility of adding methods late means that you can move methods to
other modules to decrease coupling between modules.


More information about the Squeak-dev mailing list