Rule 1: One World, One Wait-for
As embarrassing and shameful as it is for a man of principle to
have to do, I must confess I have compromised this rule somewhat
in order to actually accomplish real work. I tried breaking down
slowly, one continent, one wait-for, one nation, one wait-for,
one state, one wait-for until eventually abandoning the whole concept
of geographical I/O blocking. I tried maintaining a higher standard
on a more ethereal plane, one internetwork, one wait-for, one wan,
one wait-for, one lan, one wait-for.... Eventually that too became
too much for me, and I was forced to compromise my principles further.
I toyed briefly with the concept of one CPU, one wait-for. but
my users clamored and haunted me. Now, broken and dejected, I
have drawn a line in the sand. Do what you will, it stops here.
I will go no further: One session, one wait-for.
Rule 2: One Frame, One (Persistent) Procedure
Once you do all the compromising I did above, it becomes easy
to view this as an extraordinarily flexible rule. After all,
we could have started from one widget, one persistent procedure.
(I'm still not sure that's not where we eventually want to go,
but I'm waiting for PSC to give us packages/modules/units.)
The procedure controls all aspects of the user interaction
with the frame and its widgets.
Rule 3: Never argue with a widget.
I used to tell people not to fight the ADE, but then I could
find an ADE which wrote programs the way I wanted them done.
The essence of this advice is that as soon as what you want
to do becomes overly difficult, you should stop and ask yourself
what you're trying to accomplish.
Rule 4: No shared variables in persistent procedures.
This rule is much stricter than it needs to be, but on the
other hand,
"Put on your seat belt before having an accident."
is pretty good advice too. If you want to share data amongst
persistent procedures, create a persistent procedure to hold
the data and functions to access and set them.
Rule 5: User Interface procedures do no work.
The purpose of the User Interface procedure is to communicate
with the user. Nothing else. No record reading, no record
updating, no record creation. This is a difficult rule to follow,
and a fair number of you are going to argue with it. Too
bad. This is a natural consequence of event-driven programming -
and a natural extension of the de-coupling of user interface
and data maintenance.
When the day comes that you're on machine A, your data is
on machine C and in between is machine B which handles all
data maintenance, you'll be ready. You'll smile, and move
the code from your persistent procedure which is not in
your UI procedure on to machine B.
Rule 6: No lock spans a user interaction.
Locks are data maintenance. We've all discussed this one
before. I see by recent traffic that some of you don't
believe me. This is especially disconcerting when coming
from folks who we thought were bringing us low altitude
satellites for the world wide data network which will allow
Brad in Melbourne to lock the customer record and go home before
Susan in London even gets to the office.
Rule 7: No record scope spans a user interaction
Put bluntly, all records are strongly scoped to be
contained within an internal procedure.
Rule 8: Reports and Batch programs are, by nature, procedural.
Don't forget all of the things you learned from the
procedural paradigm just because the UI is now event driven.