[squeak-dev] Separation of domain from UI in Squeak (was: 5.3 cannot rename subclasses of Error)

Jakob Reschke forums.jakob at resfarm.de
Sat Feb 29 17:48:02 UTC 2020


Am Sa., 29. Feb. 2020 um 03:23 Uhr schrieb tim Rowledge <tim at rowledge.org>:
> An obvious problem with the current implementation is that it carries very little helpful information (notwithstanding Marcel's BlockClosure>>#valueSupplyingAnswers: try-to-do-it-all method) for the handler to decode. We seem to need to know an awful lot about what is going on in called code.

Agreed. And in a catch-all handler, how do you know which details you
can access in the current handler invocation?

> It might be neat if we could find a way to handle the exception within a terminal environment; maybe with 'curses' (that's probably dating me horribly) or zenity or whatever. Possibly helpful for nominally headless setups?

If we had all these request exceptions Christoph and me are writing
about, I'd imagine the fallback handlers would sit in the Project
subclass. MorphicProject opens the UserDialogBoxMorph, MVCProject does
its equivalent thing, HeadlessProject must already know all the
answers or abort with an error, TerminalProject (sounds like the last
one before the program dies...) pops up the request with the imaginary
curses UI.

Also note that opening a debugger is a special case of all of this:
the debugger is the UI for the request of how to proceed in the event
of an error, warning or interrupt/halt/breakpoint.


More information about the Squeak-dev mailing list