Defmod Extension

[Jonathan Coxhead]

   Tony wrote ...

 | 1. I propose to extend DefMod to accept macro definitions in swi files,
 | so that I can define some macros to use for filling in the various
 | offset fields in (for instance) toolbox object templates.

   Could you describe what you want to achieve by the change in more detail?

   The neat thing about the SWI files is that they are language-independent
---at the moment, they usefully target only C and ObjAsm, but I did a 
little work on targetting Norcroft Pascal, and C++ (natively). Java 
(invoking native methods directly) is an obvious possible future direction, 
also Haskell/HUGS, and even CORBA IDL would be a possibility.

   Though these are all hopeless pipedreams :-), it would be nice not to 
rule any of them out unnecessarily. If what you want to do can be expressed 
in a language-independent way---divorced from details of how it's 
implemented as macros, declarations, or whatever---it would be good to do 
that.

   For example, if there's ever going to be a native C++ interface, we will 
be able to express the base/extension mechanism, which is expressed in C by 
generating macros ending in _MEMBERS, as class inheritance. That was the 
real point of doing it that way---it's an expression of an object-oriented 
design, which just happens to have a macro implementation when it targets a 
non-O O language (C).

 | I recognise that it would be nicer to somehow generate these macros
 | automatically by enhancing the syntax for declaring structures, but I
 | suspect that that would over-complicating matters for not much gain.

   So I can see you obviously have a particular class of problem in mind, 
and a more abstract solution might be possible. COuld you explain more?

 | My proposal is therefore 

   [implementation details omitted]

 | 2. A further revision I propose to make to DefMod will be to alter
 | cstrong to split up the manuals into constants, types, swis, and macros
 | for each module, and also alphabetically sort each entry in the index,
 | so as to make the larger ones more manageable.

   This looks like a fine idea.

 | 3. As pointed out by users, we seem to have lost our way a little when
 | we changed the handling of variable-size structures, in that there is
 | still no base structure (with no variable members) defined, other than
 | in the macro, which doesn't appear in the stronghelp manual, and things
 | which were supposed to be just headers contain a single data member.
 | 
 | To correct the situation, I have done the following:
 | 
 | a. The macro is emitted to stronghelp, and cross referenced where used.
 | 
 | b. A structure, with the name suffixed by _base is now generated, and
 | emitted to the c header and stronghelp, as well as the legacy struct,
 | e.g.
 | 
 | struct wimp_window_base
 | { wimp_WINDOW_MEMBERS
 | };

   This all looks good too.

 | This gets a bit silly for, say, toolbox_action_header, where we now have
 | toolbox_action_header_base; this would really have been better named
 | toolbox_action_base, but for backwards compatibility I see no other
 | simple solution.

   Here's what I've done when I want to introduce a new naming convention:

      (a) Define the new (preferred) name ("a") as the thing.

      (b) Introduce a typedef of the old name ("b"). DefMod allows this as

             TYPE b = a

      (c) Forget about the old name "b" and the naming convention that
          implied it---in other words, don't continue the old naming
          convention in new software, just use the new from now on. (This
          is only relevant when writing a new module.)

   So you would implement your new scheme, but add

      TYPE Toolbox_ActionHeaderBase = Toolbox_ActionBase "Compatibility"

to "toolbox.swi".

        /|
 o o o (_|/
        /|
       (_/