On 12 August 2013 20:10, David T. Lewis <lewis at mail.msen.com> wrote:
> On Mon, Aug 12, 2013 at 08:25:33PM +0200, Bert Freudenberg wrote:
>>
>> On 2013-08-12, at 20:09, Frank Shearar <frank.shearar at gmail.com> wrote:
>>
>> > On 12 August 2013 16:42, Bert Freudenberg <bert at freudenbergs.de> wrote:
>> >> Also, what's wrong with "Utilities updateFromServer"? Seems to me much nicer and easier to remember than "MCMcmUpdater updateFromServer". Call it a Facade, if you need to appease the gods of agile ;)
>> >
>> > * I want Utilities to die. It's a mess of mixed responsibilities. Even
>> > were that all cleaned up, it'd be a mess of mixed responsibilities
>> > delegated to better suited places. It's Bad(tm) for modularity:
>> > Utilities >> #updateFromServer makes System depend on
>> > MonticelloConfiguration, which is already dependent on System.
>> > Breaking that cycle is the whole point of this commit.
>> >
>> > * With MCMcmUpdater >> #updateFromServer we concentrate updating in one place.
>> >
>> > frank
>>
>>
>> Maybe we need some high-level package then that can easily depend on all the stuff. MCMcmUpdater is just the mechanism, but the intent is something like "Squeak updateFromServer" (or even just "Squeak update").

Well, that's a fair point. Another solution to the problem I'm trying
to address would be to move Utilities out of System.

>> Utilities used to be that place. I'm fine with something different, but having a gazillion single-purpose classes for such high-level operations seems to make things harder on users, not simpler.
>>
>> Discussion welcome, of course :)

There might be some bits lets over, but I'd like to see at least the
following things moved out of Utilities:
* finding pointers: Utilities >> #pointersTo:except: already lives in
PointerFinder
* the identification protocol in its entirety belongs in a class
called something like SystemAuthor
* the old update stream stuff really ought to go
* move the selector hacking stuff to Symbol
(#inherentSelectorForGetter:, I'm looking at you!)
* any other methods that take a single parameter and construct
something based on that parameter really belongs with the (expected)
parameter's class. (The general case of the
#inherentSelectorForGetter: example.)

>> - Bert -
>>
>
> It walks like a utility and it quacks like a utility, so I think it's a Utility.

Well, there are Utilities, and there are dumping grounds for things
you can't immediately find the proper place for, and just dump it any
old place.

frank

> Dave
>
>