Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!husc6!think!ames!ucbcad!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.mac
Subject: Re: Configurability (Was: Re: Big Mac Systems)
Message-ID: <8705211910.AA21535@cory.Berkeley.EDU>
Date: Thu, 21-May-87 15:10:02 EDT
Article-I.D.: cory.8705211910.AA21535
Posted: Thu May 21 15:10:02 1987
Date-Received: Sat, 23-May-87 12:12:31 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 21

>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