Hey Speedy, thank you for giving a grace period for discussion.  I do
indeed think we should talk about this!  :)

First, everyone agrees we don't want to have UI code buried in
"domain" code.  Everyone also agrees we want to get rid of cyclic
package dependencies.

But let's decide whether it's ok to have the *concept* of a UI buried
in domain code.  For example, if I say,

   Warning signal: 'Are you sure you want to format your hard drive?'

under normal circumstances the user will have the option to Proceed or
Abandon.  But since Warning is resumable it can also be controlled to
run headless to automatically resume.

So is THIS an example of burying UI code in domain code?  I don't see
it as such.  I think it's ok to acknowledge the *concept* of a User in
domain code as long as it doesn't create a dependency on any
_particular_ UI implementation.

This appears to be the original purpose of UIManager.  So why can't we
extract its "worth" the way it is?  Maybe because it's simply in the
wrong package?  What the superclass, UIManager, were moved to, say,
Kernel?

Please note, we already have ProvideAnswerNotification, and that's why
I instinctively resist adding new resumable Exceptions to the system
just because of this.  Because we already have something close to this
and so adding yet another layer of notification really confuses the
API for how it should be used.

One of my favorite sayings (from Dan Ingalls, I think!) is:  "If you
have two things that are almost the same, you should either make them
the same or make them very different."

That would seem to be the case here if we were to introduce new
resumable Exceptions.  Let's comb harder for a solution that uses the
infrastructure we have..



On Sun, Jul 21, 2013 at 4:26 PM, Frank Shearar <frank.shearar at gmail.com> wrote:
> A whole bunch of low level packages - Network, Graphics, and so on -
> depend on ToolBuilder because of UIManager's #request:initialAnswer:,
> #inform:, and so on.
>
> This in turn causes transitive dependencies on Collections, Files,
> Kernel, SUnit (!) and System and, in particular, causes a cycle
> between Graphics and ToolBuilder-Kernel.
>
> I propose adding a few new resumable exceptions to some low level
> package (perhaps Kernel, perhaps something else) that would follow the
> pattern of ReplaceExistingFileException. The base package would
> contain the definition, and ToolBuilder-Kernel would decorate the
> exception with default handlers. So, concretely, we'd have something
> like
>
> Notification subclass: #InformNotification.
>
> InformNotification class >> inform: aString
>     ^ (self basicNew initializeWithMessage: aString) signal
>
> InformNotification >> defaultAction
>     "*ToolBuilder-Kernel category"
>     ^ UIManager default inform: message
>
> This would allow Graphics (and other packages) to signal stuff, while
> not depending on ToolBuilder.
>
> This is a fair amount of work - 19 users of UIManager in Network alone
> - and it's fairly noisy in that it'll touch quite a few classes. So
> before I dive in and break everything again.... are we reasonably
> happy with this approach? I'll wait until Tuesday or Wednesday before
> starting this, just to let Chris Muller say "wait wait wait let's talk
> about this first!" :)
>
> frank
>