Global Conflicts II

[TBaehr@xxxxxxxx]

Carl raised some interesting questions about the XPL routines native to
XyWrite. He wondered, for instance, why we waste 12 bytes of code and a
>750K file just to set the error number to 11. Assuming ES is
set to 1, all you need is BX(). Right. But in our routines, we
couldn't count on ES always being 1 -- so we set it to 1 and then
set it back. That kind of safety is good programming: never
making assumptions about the current state.
 As for having to load an entire file -- why not, if you're using it anyway?
 And if you're not, you can create your own mini-DLG file with
just the global stuff you want to use in your programs.

Another issue is the use of "reusable" S/Gs. I was perhaps not
as precise as needed in my explanations. The S/Gs can of course
be used as-is if nothing else conflicts. But generally the
practice was to assign (for instance) S/G
40 to an output and then, in the "calling" routine, transfer that
value to another S/G (≪SX1001,≪IS40≫≫).

Were we a bit sloppy in our assignment and use of S/Gs? You bet.
 Could we have done better? Sure. Why didn't we? Resource
limitatons, time limitations, inexperience. Could it have been worse? Lots. Dave invented
XPL as a largely unstructured language, and that invited all
sorts of ad-hoc programming methods (and non-methods). Spaghetti
was the reigning monarch.
 We did, toward the end, try to make some things regular.
1800-level S/Gs are used for variables that need to stick around
for a work session.
 1900-level S/Gs are used for variables that we want to save to
disk for permanent use. 1300-level has generally been for subroutines. 100-999 and
1400 - 1700 we left alone for users or 3rd-party developers. The
general plan for the rest was for 1000-1099 to be for the first
part of a series of operations (like the first dialog box) and
1100-1199 for the second part, etc. That didn't always hold. I
did impose a system on most formatting S/Gs so, for instance, the
one for left offset was always the same number. That kept me
from going nuts with the styles routines. But a lot of S/G
assignments crept into inconsistency to the point that, in my
opinion, trying to fix them (given resources) could introduce
bugs. And then something new would have come up requiring
another complete reorganization, etc., etc. At no time did we
have more than 3 or 4 XPL coders on board; when I started, only
one had experience with menus. In an ideal world, there would be
a complete overhaul of the XPL-based stuff in XyWrite, with
assigned ranges, a tighter naming system for dialogs and
routines, a "syntax" of how to lay out a routine, etc. I can
guess that it won't happen.

Tim Baehr