ajh@sdcsvax.UUCP (Alan Hu) (08/30/83)
I hate to see such a trivial issue cloud an important newsgroup, but I have a big mouth, and I can't keep it shut any longer. Let's see if we can shed some light on this issue by analogy to everyone's favorite subject. Yes, COMPUTERS! Now, suppose that you must write a module/procedure/subroutine that has to interact with some external object/variable/device. You, if you like bug free programs, should follow certain rules to help ensure no conflicts. Among these are, (1) Don't presume the state of the external thing. Initialize it first. (2) While you are accessing this thing, you must prevent others from accessing it simultaneously. (3) When you're done, you should leave it in the state in which you found it, so as not to disturb other functions. Applying these rules to toilet etiquette: (1) Don't assume the toilet is in a given configuration. You might be in for some surprises! (2) This shouldn't be much of a problem. You should probably lock the door or close the latch. (3) Before you initialize the toilet, make a note of the state. Before you exit, restore the toilet to its previous state. (This rule handles the case of toilet trained cats, who can't handle certain protocols. By following this rule you ensure that you don't disturb some other process.) (This rule is subject to modification, just as a routine will have side effects, you may, too. Just be sure that they are well defined, and that you know what you're doing.) Obviously, if you are familier with the other people with whom you must interract, you can arrange different protocols, like warm-seat-down, etc. You must then adhere to these protocols. You might want to publish them for distribution to the creators of transient processes (ie. guests). If there be enough interest, you might even get an ANSI or ISO standard on toilet management protocols! :-) In partial jest, Alan J. Hu sdcsvax!ajh