User interaction vs. headlessness vs. exception handling

Ned Konz ned at bike-nomad.com
Mon Jul 24 02:02:19 UTC 2000


I've been looking at Squeak to use it headless for a couple of things.
However, I notice that there is a distressing tendency in low-level
routines to call the user interface, often to pop up a menu or a
fill-in-the-blank dialog.

Should there REALLY be a dependency between, say, StandardFileStream
and the UI?

Why can't I just get an exception raised, which I can detect and deal
with as I please? Squeak has fine exception handling, after all...
isn't anyone using it in the UI?

Here are (some of) the places that do UI interaction when (IMO) they
shouldn't:

FTPSocket>>lookFor:
FTPSocket>>lookSoftlyFor:
FTPSocket>>responseError
FTPSocket>>responseOK
HTTPSocket class>>httpGetDocument:args:accept:request:
HTTPSocket class>>httpPostDocument:args:accept:request:
HTTPSocket class>>httpPostMultipart:args:accept:request:
IRCConnection>>connect
StandardFileStream class>>newFileNamed:
StandardFileStream class>>oldFileNamed:
StandardFileStream class>>readOnlyFileNamed:
Class>>rename:

I'd much prefer to see, for instance, readOnlyFileNamed: raise
an exception if there is no file by that name.

And there could be a method in Utilities or somewhere that could
interact with the user if there is not.

Especially since the StandardFileStream stuff is called from
other methods that don't give any indication that they will
pop up a menu (like many methods in FileDirectory and FileStream
class).

I can just imagine a headless server popping up a menu to a
non-existent bitmap somewhere and hanging forever...

-- 
Ned Konz
currently: Stanwood, WA
email:     ned at bike-nomad.com
homepage:  http://bike-nomad.com





More information about the Squeak-dev mailing list