Q:  Regarding ANNOUNCE & REQUEST -- what was wrong with using the word
    EXTERNAL and what is the advantage of CA switching to the word REQUEST?

A:  [Don Caton:]

    The words "ANNOUNCE" and "REQUEST" more accurately describe
    what's happening.  Too much of our terminology is vague or arcane, and
    I think it was a cool idea to implement these things.  They can always
    clean up the underlying implementation without affecting the end result.

    ANNOUNCE declares a public symbol for a particular module.  It's like a
    module saying "if you're looking for a bunch of code named xxx, here I
    am".  It just gives an identifying name to a source code module
    (generally an .obj file) so that it can be pulled into your application
    even if none of the routines in that module are called directly (which
    would normally cause it to be linked in anyhow).

    Probably the main reason this was implemented is that INIT and EXIT
    procs generate private names so they're not visible to the linker, and
    some mechanism like this was necessary to instruct the linker to include
    them. ANNOUNCE/REQUEST allows modules like this to stay in libraries and still
    get linked instead of having to explicitly link them as obj files or use
    special linker instructions.

    This technique has been used internally in Clipper for some time.  For
    example, when you compile with /b the compiler automatically includes
    something similar to a 'REQUEST _VDBG' in the generated obj file.
    Inside CLIPPER.LIB, there is a module named vdbg.obj which has the
    equivalent of an 'ANNOUNCE _VDBG' inside.  The linker matches them up
    and, voila!  This is how the debugger stuff gets pulled in
    automagically.  The module vdbg.obj references other stuff that the
    debugger needs and it starts off a chain reaction which isn't complete
    until all the necessary modules are found by the linker.

    As you can see, the request for a single identifier can pull in a whole
    sybsystem.  It's something that perhaps many Clipper programmers won't
    need to use, but if you're putting together your own code libraries,
    it's definitely something worth investigating.

Q:  But doesn't "REQUEST" do exactly the same thing "EXTERNAL" used to do?
    Also, isn't "EXTERNAL" used in Assembly and "EXTERN" used in C?
    Not to belabor the point, but I'm just curious as to why you think
    "REQUEST" more accurately describes what's happening.

A:  [Robert diFalco:]

    Yes, REQUEST is the same as EXTERNAL. However, EXTERNAL is just
    kind of a stupid name. When you do an "EXTERNAL DESCEND" what you
    really mean is "REQUEST DESCEND". Since we are getting into
    dynamic modules with Clipper with such things as RDD's and
    INIT/EXIT PROCEDUREs we needed a sane and readable way to deal
    with them without having the old "you must link this object
    file into the root". 
    
    Therefore, with a third party product such as SuccessWare's DBFSix,
    for example, you would just add "REQUEST DBFSix" at the top of your
    main PRG file.  ANNOUNCE allows you to create a REQUESTable module
    identifier for a module of routines. As Don, said, the implementation
    can always be changed but the decisions were correct. Here's an
    example of how to use it in a different way than described above.

    Say that you have three clients that all have the same essential code,
    code you put in a library for reuse. However, one of the three clients
    wants LOTUS style menus, one wants BOX menus and another wants Pull-Down
    menus.  If all your menu subsystem protocols are the same, you would put
    each engine into a different .LIB with an OBJ ANNOUNCEing each type.
    Hence, you would solve your problem by simply adding this line to the top
    of "Client C"'s application:

         REQUEST PullDown   // or LOTUSMENU or BOXMENU

    No this is a simple example and there may be other soloutions, but it
    should give you some ideas as to how to modularize dynamic code.  For
    example, Client specific code could REQUEST a special ANNOUNCEd module
    specific to that Client.

       REQUEST clientXYZ

    [Don Caton:]

    I think "REQUEST" more accurately describes what's happening because the
    presence of that statement means that you are _requesting_ the named
    module to be linked into the application.  Yes, it's exactly the same as
    the "extrn" declarator in assembly (in effect, but not in implementation),
    but it isn't the same as "extern" in C.

    The "extern" keyword in C is a modifier and means two different things:
    one, it's placed in front of a variable declaration to indicate that
    storage for the variable is declared somewhere else, i.e. "external" to
    the module the declaration appears in.  It instructs the compiler not to
    generate any storage space for that variable in the module being compiled.

    The other use is as a modifier in a function prototype.  In that context,
    "extern" indicates that the function body exists somewhere else; again,
    "external" to the current source module (this usage is superfluous).

    Neither of these uses of extern have any parallel in Clipper.  The mere
    presence of a statement like 'extern int xyz;' does not generate a
    request for the symbol 'xyz', you actually have to reference 'xyz'
    somewhere in the code for the C compiler to generate an extdef for
    the symbol.  Same with function prototypes declared as extern.
    If that was sufficient to pull in a symbol, just including an
    .H file with prototypes would drag in unnecessary code.

    There really isn't anything like Clipper's REQUEST in the C language.
    In C you have to do something like:

           extern int xyz;

           static void DoNothing( void ) {
              int dummy = xyz;
           }

    You would never call this routine but the compiler doesn't know that,
    and it causes whatever module that defines 'xyz' to be linked in.

    In the Obscure Trivia Dept., a routine exactly like the one above
    appears in some of Clipper's RDD modules in order to get their
    superclass RDD's dyn modules linked in (which, like Clipper's
    INIT/EXIT functions, are mostly invisible to the linker as well).

    There was no prior equivalent to ANNOUNCE in Clipper, although
    you could achieve the same result by declaring a function or
    procedure with the desired name and just don't put any code in it
    (which is exactly what ANNOUNCE does anyhow).

Q:  What do you mean by the term "dynamic modules"?  Does that simply mean
    that the particular module requested may change depending on the
    situation or particular need at the time?

A:  [diFalco] In this context I was referring to modules which have no
    explicit references to them in other parts of the EXE.  This would
    be the case in a data-driven application, for example.
