[squeak-dev] Re: Package Hierarchy Map

Frank Shearar frank.shearar at gmail.com
Fri Jul 26 17:47:29 UTC 2013


On 26 July 2013 17:25, Chris Muller <ma.chris.m at gmail.com> 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.  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".

I mildly object to the description 'being driven by "any
> place but here because it creates a cycle"' :). I think losing the cycle is more important than which edge goes, is all. While we're slicing things up, we'll get things wrong, but it's easy enough to move bits around. We'll only really get a proper idea of when we've messed up when we unload things and what's left breaks.

We're largely in agreement as to what's high- and what's low-level.
Mainly we disagree about System: you _want_ it to be a low-level thing
while I _see_ it as a high-level package. Of course, that's because it
has low level parts and high level parts. Not surprising, given that
the only packages larger (*) are Morphic, MorphicExtras and Etoys!

(*) ((PackageInfo allInstances collect: [:pkg| {pkg name. pkg classes
size. pkg extensionMethods size}]) sorted: [:a :b | (a second + a
third) < (b second + b third)]) reverse first: 5
"=> #(#('EToys' 125 630) #('Morphic' 220 127) #('MorphicExtras' 128
143) #('System' 127 83) #('Tools' 64 120))"

> It probably won't be possible to eliminate the cycles between the
> three lowest-level packages, but hopefully from the ones above that.

I do think _ideally_ that Kernel would have no dependencies at all.
But doing that would require drastically altering the contents of
Collections. But that's a problem for much later.

Morphic and ST80 fulfil the same function: supplying a user interface.
(I know that's obvious.)

Text should probably be broken out into a separate package, in which
multilingualisation, Strings and other such stuff would reside. At the
moment text handling's spread all over the place: Collections,
Multilingual, Morphic, perhaps part of System too. (I'm running off
memory of an experiment I tried and threw away a few days ago.)

frank


More information about the Squeak-dev mailing list