On 26 July 2013 20:42, Chris Muller <ma.chris.m at gmail.com> wrote:
> 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..

And they're good ideas too. A bit +1 to Dave's talking about
approaching packages the way we do objects. So for instance, since you
mention SmartRefStream, there's a whole pile of stuff concerned with
moving objects into and out of the image. DiskProxy, the
"System-Object Storage" subcategory, and so on. Breaking all those
guys into a package focused just on this would (a) make a lot of sense
because things that work together would be grouped together and (b)
would make untangling the system as a whole much easier.

frank