XCMD Libraries
Volume Number: 5
Issue Number: 6
Column Tag: HyperChat™
XCMD Corner: XCMD Libraries 
By Donald Koscheka, Arthur Young & Co., MacTutor Contributing Editor
Modularity and Coupling
As you to explore XCMDs, you should continue to discover new and interesting
properties of these routines. Two properties are particularly noteworthy because
they lead to code that is usable outside of Hypercard. They are strong modularity and
weak coupling.
You determine the modularity of a routine by counting the number of tasks it
performs. Strongly modular routines handle one task. If you were writing a
spreadsheet program, you would most likely separate the routine that calculates the
value of a cell from the routine that displays that value. Combining these functions
results in weak modularity. Weakly modular code is hard to debug because you can
easily lose track of what the routine is doing at a given point.
Coupling describes how the program interacts with the outside world. Weakly
coupled routines operate only on data passed as formal parameters. Weak coupling
eliminates harmful side-effects caused by relying on global memory. Weakly coupled
programs force you to think over how and when to pass data back and forth.
Well written XCMDs exhibit both strong modularity and weak coupling. Most
XCMDs perform one task (strongly modular XCMDs), typically to add a missing feature
to Hypertalk. XCMDs interface to Hypertalk using a very strict protocol, passing
parameters via the command block record. This protocol coerces weakly coupling in
your code.
Software Breadboard
Strong modularity and weak coupling suggest that you can create libraries of
useful routines for use both in Hypercard and in programs of your own design. Think
of Hypercard as a “Software Breadboard”, a test platform that you plug code into for
checkout and debugging. Once working, the routine can be dropped into any application.
An example of a set of routines that play well in this scenario are the calls to the
File Manager. Every (non-trivial) application needs to call on the file manager to open
a file, access information in the file and then close it. I decided to build my case around
accessing a file because Hypercard itself doesn’t handle files “according to Hoyle”.
Hypercard violates two precepts of the user interface guidelines when opening a file:
(1) The user is required to know the full pathname of a file if it is not in the current
working directory and (2) the OpenFile command performs an unexpected action; if it
cannot find the file, it creates it!
In order to properly open a file, you first present the user with a dialog that
contains the list of files in the current working directory. This dialog allows the user
to flip from drive to drive as well as change directories. The standard file package
provides you with the “vanilla” get file dialog. When the user selects a file and clicks
the “Open” button, your code queries the reply record to discover the file’s name,
working directory id and file type.
The working directory id pinpoints which folder contains the document. If you
made a killing on Macintosh software and have been away on some deserted island for
the past several years, the working directory assumes the role traditionally held by
the volume reference number.
Given the file name and working directory, you can reconstruct and return the
full pathname to Hypercard so that it can be used by Hypercard’s “open” command
(pathname reconstruction is the subject of a future article). However, it’s just as
easy to open the file ourselves to ensure that it opens in whatever manner is expected
on the Macintosh. The XCMD that opens the file is left as an exercise.
GetFileName XFCN
The XFCN, GetFileName (Listing 1), displays strong modularity - its sole task is