simpson%trwarcadia.uucp@usc.edu (Scott Simpson) (05/17/89)
I have been using xdbx, the X interface that sits on top of dbx. With all the emphasis on UIMSs these days, it occurred to me that a better approach to layering a new human interface on dbx is to define that interface as an abstract data type (ADT) and then to attach a new human interface to the ADT rather than to try to munge a new human interface on top of an old human interface like xdbx does. For example, a common dbx programmatic interface may have operations such as /* Set a breakpoint at the specified source line. Returns * an error code if it fails. */ int stop_at(file_name, line_no) char *file_name; int line_no; /* Set a breakpoint in the specified function. */ int stop_in(function_name, line_no) char *function_name; int line_no; /* Set the directories to search for files. */ int use(list) char *list[]; /* Returns a list of the current directories to search for files. */ char **get_use() The problem with xdbx is that dbx often times maintains current state that xdbx doesn't know about. For example, if I use a "use" command to xdbx, and then pick the "file" button in xdbx, xdbx doesn't know anything about other directories I care to search and doesn't give me the option of picking files in other directories. Of course writing an interface like the one above involves rewriting the guts of dbx but it isolates dependencies behind the program interface and allows reuse of the programmatic interface by multiple tools (i.e., dbx and xdbx). It also doesn't force you to go through the horrible task of parsing the output of dbx. Comments? Scott Simpson TRW Space and Defense Sector oberon!trwarcadia!simpson (UUCP) trwarcadia!simpson@usc.edu (Internet)