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 |
On 21-07-2013, at 2:26 PM, Frank Shearar <[hidden email]> wrote: > 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. Yes. Low-level code really shouldn't be directly talking to UI stuff. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: L: Lie! |
In reply to this post by Frank Shearar-3
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 <[hidden email]> 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 > |
Free forum by Nabble | Edit this page |