On Fri, Jul 26, 2013 at 11:25:50AM -0500, Chris Muller wrote:
> One thing that might help us sort methods and organize methods into
> packages is try to decide what we think the responsibilities of those
> packages are.

+1000

I have not put much thought into the specifics, so I won't try to
comment on the suggested hierarchy (yet). But I do think that it is
very important that packages make sense conceptually. Thinking about
it in terms of responsibilities for a package seems like the right
thing to do. That's the approach that any of us would take in thinking
about e.g. the responsibilities of a class in an object oriented
design. So it seems natural to think of packages in the same way.

Dave

>  Here is a suggested hierarchy where the most-indented
> are the lowest level packages and the most outdented are the highest
> level packages.
> 
> I might be helpful to be driven by where we think, *semantically*, the
> behaviors you're moving around belong rather than being driven by "any
> place but here because it creates a cycle".
> 
> It probably won't be possible to eliminate the cycles between the
> three lowest-level packages, but hopefully from the ones above that.
> 
> Morphic
> (and everything else)
>      ST80 -- Not sure about this one, but seems like it should be
> "legacy" Smalltalk stuff rather than low-level stuff.
>           Tools -- Domain models that describe and operate tool windows.
>                System -- catch-all for System'y things.  Does not
> include any tool-windows.
>                Balloon -- Graphics framework.
>                     Graphics -- Things related to graphical output.
> Bit-blitting and canvas stuff.  NOT Morphic stuff.
>                     Multilingual -- Things related to internationalization.
>                          Kernel -- Lowest-level things besides
> collections and error-handling.
>                               Collections -- collections.
>                                    Exceptions -- Error-handling things.
> 
> Thoughts?