Implicit initialization is EVIL!

Chris Angelico rosuav at gmail.com
Mon Jul 4 13:41:44 EDT 2011


On Tue, Jul 5, 2011 at 3:09 AM, rantingrick <rantingrick at gmail.com> wrote:
> On Jul 4, 11:01 am, Chris Angelico <ros... at gmail.com> wrote:
>> This is not
>> a modal dialog; it's not even a modeless dialog - it's a completely
>> stand-alone window that can be moved around the Z order independently
>> of the parent.
>
> You can do the exact same thing with Tkinter's windows.

I didn't say Tkinter couldn't do this; I said that it was a good thing
to be able to do, which you earlier decried.

> However in this case you should spawn a new instance of the
> application "opened" at that particular table view. It's as simple as
> a few command line arguments in your script.

No! Definitely not. Initializing the application includes logging in
to the database. Suppose the user had to log in again... or, worse,
suppose I transmitted the username and password via command line
arguments. No, forcing programmers into a particular coding model is a
bad idea. Let the individual programmer decide what tool is best for
what job.

> It's like a text editor, you never want a "New" command that resets
> the current document or an open command that resets the current
> document and loads the file into the existing editor. Each application
> instance should only create one document and stick with it until it is
> closed.

What, never? Well, hardly ever! (As per HMS Pinafore, if you're wondering.)

Actually, I quite frequently do want exactly that. Replace the current
buffer with a new document. Keeping the previous document involves one
of two choices (maybe more, but I can't think of any off hand):

* Leave the other document visible on the screen, cluttering things up
and forcing the user to switch to the other window, close it, and then
return to his work; or
* Have the new window completely and exactly mask the old one, making
it unobvious that the previous document is actually still open,
leaving enormous possibilities for confusion.

Audacity takes the first option (at least, the Windows version that I
used five years ago did). You choose New or Open, it brings up another
window. This astonished me when I first saw it (strike one), annoys me
85% of the time and is useful only 15% (strike two), and tends to get
in the way of rapid keyboard-oriented navigation (strike three and
out). I'd much rather Audacity kept all its "stuff" in one window,
unless I explicitly asked it for another window.

For another example, look at where web browsers are going. By your
description, one instance of a browser should work with precisely one
"document" (which in this case would be a web page). That's how
browsers were in the early days, but by the early 2000s most browsers
had some form of tabs, letting you keep that application in one
window.

> Instead you want to spawn a new instance of the editor and tell the
> editor (via command line arguments) to load file data (if applicable).
> Simple command line arguments (of which you should be using anyway)
> are the key here. All part of proper software design.

Of course I could spawn a new instance. But why? Why do it? And if I
have to have a completely new copy of all the editor's state, this is
hopelessly inefficient on memory and startup work. Why should
File|Open incur such a cost? (Ameliorated if you fork() but that has
its own consequences.) But the memory cost is nothing compared to the
extra interference it puts on "mindspace".

I currently have precisely two slots in mindspace for web browsers:
Chrome and Firefox. Chrome currently has about a dozen tabs up;
Firefox about the same, but most of them are long-term status reports
that I keep handy. If I had to have 20-30 separate windows, I would
not be able to use alt-tab to find the one I want, but would have to
use some other kind of "window picker". How would you write a
user-friendly picker that can cope with myriad instances of
everything? My guess is that it'd use some kind of tree structure with
applications at one level and windows at the next. Is this not exactly
what we already have?

Chris Angelico



More information about the Python-list mailing list