chuq%plaid@Sun.COM (Chuq Von Rospach) (05/21/87)
> Couldn't it be easier for the user (not the programmer though) > to construct configurable software? Yes, and in fact I made the following suggestion to Microsoft as a requested enhancement to Word 3.0. Since it is of (hopefully) general interest to people writing large commercial programs with a number of discrete functional modules, I'll comment on it here, too. What I think programmers ought to consider is plug in functionality. For instance, Word 3.0 has a number of different, independent functional modules -- the basic WP, the outline processor, the spell-checker, the hyphenation, etc... All of these are compiled into a single large binary, meaning that even if you don't use the outliner, you carry it along on each disk you have, and you have to see the outline commands in the menus. A better alternative would be to strip the functional module into a separate resource file that lives in a known location (for instance, the System Folder). When an application starts up, it checks for the existence of that file, and if it exists, opens it as a resource file so the CODE module is accessible, and does the appropriate initialization. If it doesn't, then that part of the program is not initialized for use by the user. You could go one step futher and define an initialization interface to the program, so that the initialization is done by a CODE segment in the opened resource file -- this would mean that the main program would not need to know anything at all about what that program did (note: the interface would probably NOT be trivial, but it would be an interesting exercise). End result: third party people can write modules that plug into a program that supports this interface that become part of the program, as opposed to writing large and complicated DA's. Imagine if someone wrote a version of ACTA for word 3.0, or SpellSwell, or MacLightning. No more kludgey hacks to get control around the main application. You could even, in theory, write a shell that calls 'applications' as modules, and do everything in term of a meta-application. not exactly multi-tasking, but... anyway, It looks reasonable to me on paper. I'd be interested in hearing any holes in the proposal. chuq Chuq Von Rospach chuq@sun.COM [I don't read flames] There is no statute of limitations on stupidity
dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/21/87)
>What I think programmers ought to consider is plug in functionality. For >instance, Word 3.0 has a number of different, independent functional modules >-- the basic WP, the outline processor, the spell-checker, the hyphenation, >etc... All of these are compiled into a single large binary, meaning that >even if you don't use the outliner, you carry it along on each disk you >have, and you have to see the outline commands in the menus. The method you are describing is called an overlay tree. Although nice in concept, it can be a hassel for the programmer when using a language or OS which does not directly support dynamic module loading. For instance, if the programming was done in C on a Mac, you would loose (A) Direct global program variable access by the module, (B) Direct function call access to the module and by the module. As I said, these two little items can make the difference between a clean design and a messy one, and although you *can* get around it, it takes some messy programming to do it. The optimal solution would be to change the executable format of the modules to something which can easily be dynamically located and still have direct access to the master-program's global variables and functions. -Matt
jlc@goanna.UUCP (05/25/87)
In article <19433@sun.uucp>, chuq%plaid@Sun.COM (Chuq Von Rospach) writes: > Couldn't it be easier for the user (not the programmer though) > to construct configurable software? > > {...} > You could go one step futher and define an initialization interface to the > program, so that the initialization is done by a CODE segment in the opened > resource file -- this would mean that the main program would not need to > know anything at all about what that program did. {...} Yes, this idea is quite hot in the AI stream of object oriented programming. The only reasonable way to achieve full software configurability is to marry modules, inheritance with message passing (see Byte Aug 1986), then we could have all the bliss of independent software modules, configurable up to the users' taste - the module existance could be determined at the run time by software inter-communication. Should the software developers think more seriously about Object Pascal, MacApp, Objective C, or even home grown ideas like Skel(?).