DefMod Syntax

[Jonathan Coxhead]

   (1) On message structure names ....

 | OK, having solicited your advice, I hope you won't mind if I don't
 | take it.
 |
 | [reasoning snipped]

   That's fine. :-)

   (2) On message structure member names ...

   This is how I understand the problem.

   The question is, what do we do when the same name is used for a 
member of a base structure and also in some extension of it? One of 
them needs a new name. Should we change the name of the base member 
or of the extension member? E g: there is a |size| member in the Wimp 
message header type |Wimp_MessageHeader| and also in the body of a 
message of type |Wimp_FullMessageRAMXfer|. Do we rename the |size| in 
the message header as |message_size| or the |size| field in 
|wimp_full_message_ram_xfer| as |xfer_size|, since they now appear in 
the same structure?

   I think Tony says the base; Tom and I say the extension.

   Suppose you have some code that does things the current way. |m| 
is declared as a |wimp_message|. It uses |m.size| as the size of the 
message, and |m.data.ram_xfer.size| as the size of the RAM transfer. 
Then you convert to doing things the new way, and you declare |x| as 
a |wimp_full_message_ram_xfer|. I'm sure that it would be easier to 
convert to using |x.size| as the message size and |x.xfer_size| as 
the transfer size than to use |x.message_size| as the message size 
and |x.size| as the transfer size.

   Let's call the 2 proposals A, B: in the current situation, you 
have to write

      m.size
      m.data.ram_xfer.size

   Under A, you would also have

      x.size      == m.size
      x.xfer_size == m.data.ram_xfer.size

   Under B, you would have

      x.message_size == m.size
      x.size         == m.data.ram_xfer.size

   The thing to note is that in A, it doesn't matter exactly what 
type of message you're looking at: |m| and |x| could be of type 
|wimp_message|, |wimp_message_header| or |wimp_full_message_ram_- 
xfer|, and you always get its size with |.size|. In contract, in B, 
you need to know the exact type of the thing you are looking at. If 
it's a |wimp_message|, you have to use |.size|, but if it's a 
|wimp_message_header| or a |wimp_full_message_ram_xfer| you have to 
use |.message_size|. This is bad enough, but if you make a mistake, 
and write |x.size| by accident, then you don't get a compile-time 
error, you just get the wrong member. I think this type of mistake is 
fairly common, and would be best caught by the compiler. In contrast, 
writing |x.xfer_size| when you really want the message size would be 
harder mistake to make.

   Similarly for gadgets---given

      gadget_object       g;
      actionbutton_object a;

it's going to be easier to have (A)

      a.flags == g.flags

and

      a.action_button_flags ==
            ((actionbutton_gadget *) g.gadget)->flags

than to have (B)

      a.gadget_flags == g.flags

and

      a.flags == ((actionbutton_gadget *) g.gadget)->flags

   See how the forms across the equal signs in A are almost a pure 
syntactical rearrangement, with the same semantic components arranged 
in a different way? That's the aim, as it allows less thought to be 
used when rewriting code, and therefore fewer mistakes. (The 
discipline of Logic was once defined to me as "a means for avoiding 
thought." :-)

   I think Tom agrees with this, so this is what we will be getting 
in the gadget case. Good!

   I'm sorry if I'm repeating myself here, but there seems to be some 
communication problem---I don't really understand Tony's "more 
backwards compatibility" argument at all.

   But if I have have failed to convince, oh dear!

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