[squeak-dev] Re: Package Hierarchy Map

Chris Muller ma.chris.m at gmail.com
Fri Jul 26 19:42:26 UTC 2013


On Fri, Jul 26, 2013 at 12:47 PM, Frank Shearar <frank.shearar at gmail.com> wrote:
> 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!

I'm just trying to think about responsibilities as much as levels.
Even if MethodFinder didn't need any of the other packages Tools
depends on, it fits into the responsibility of the Tools package.

If "System" is all the little engines and services needed to make the
Smalltalk environment work, then being actually right in the _middle_
might be helpful so that factorings above or below it can slide right
into this System "catch-all" package until they can be factored out at
a future point.

For example, at some future point maybe we'd be able to factor out the
SmartRefStream into a separate package, so that another serializer
could be substituted.  The remainder of System remains intact until
hopefully it can be factored into total oblivion.

These are just ideas..


More information about the Squeak-dev mailing list