Font_ApplyFields problem

[Jonathan Coxhead]

Hi Tony,

   You've certainly made a cogently argued case. I'm sorry if I appeared to 
accuse you of bullying---that wasn't my intention. I was using the word as a 
(somewhat metaphorical) description of a coding style, not to refer to any 
individual---and certainly not you!

   I'm still uncomfortable with the idea that behaviour should change by 
default, rather than a change being requested explicitly in some way; but I 
seem to be in a minority. So unless there's a silent majority who are quietly 
agreeing with me, but only lurking (an unlikely prospect :-), I think I have to 
concede the point that most people want 32-bit file handles, but want to use 
short names.

   But I'm not out of ideas yet :-)

   How about the following as plan of action:

      ---introduce a new typedef byte os_fb, to match os_fw.
      ---rename all the byte-wide functions (in the SWI files) as
         osfile_save_stamped_b() etc

   This appears to be a retrograde step so far. Now we have 2 completely 
parallel sets of functions, one set dealing in os_fw and ending in _w(), one 
set dealing in os_fb and ending in _b().

> So, perhaps can we refine it like this:
> 
> 1. Add a switch to your putative header file:
>      # if !defined OSLIB_USE_OS_F8	
>        #define os_f                 os_fw
>        #define xosfile_save_stamped xosfile_save_stamped_w
>        #define osfile_save_stamped  osfile_save_stamped_w
>        ... etc ...
>      #endif
> 
> 2. Add a NEEDS osf32 to the appropriate SWI files to spare the user the
> *extra work* of specifying his own #include. This also obviates the need for the
> tests in osf32.h, with the consequent inconvenience (*extra work*) to the user
> of a compile time error if the #includes are in the wrong order. 

   This is an *excellent* idea---much better than my "osf32.h". We could use it 
slightly differently though.

   Suppose osfile.swi contained "NEEDS osfile32", and we supply a header 
osfile32.h as follows:

      #ifndef osfile32_H
      #define osfile32_H

      #if !defined OSLIB_F8
      #define os_f                 os_fw
      #define xosfile_save_stamped xosfile_save_stamped_w
      #define osfile_save_stamped  osfile_save_stamped_w
      ... etc ...
      #else
      #define os_f                 os_fb
      #define xosfile_save_stamped xosfile_save_stamped_b
      #define osfile_save_stamped  osfile_save_stamped_b
      ... etc ...
      #endif

      #endif

   This makes the switch clearer, and more symmetrical. If you desperately need 
to call an 8- (_b) or 32-bit (_w) version explicitly, you can; you get 32 bits 
by default, using short names; and you can still switch to 8 bits by adding a
-DOSLIB_F8 to your command line.

   There would be one file like the above for each SWI file that used os_f file 
handles (colourtrans32.h, devicefs32.h, etc). The typical OSLib user would 
never see them though: they are included automatically.

> 3. Add a comment to the help text for OS_F and all the 8-bit functions,
> telling the user to #define OSLIB_USE_OS_F8 if he really wants 8-bit handles.

   Yep, though I'd use a shorter name---OS is present twice, USE is kinda 
redeundant, giving OSLIB_F8.

> Any user who needs 8-bit binary compatibility will get it by default; any
> user (there can't be many) who opts for 8-bit source compatibility can set
> the switch in his make file (surely that's minimal *extra work*); anyone else
> gets PRM-compliant 32-bit handles. Everyone can use the short symbols, and
> migrate from 8 to 32 bit by simply undefining a constant. Would that finally
> satisfy everyone?

   Yayy!!

> There are a couple of aspects to this which need further consideration.
> Firstly, something similar needs to be done for assembler headers,

   The same idea should work for those---OSFile32.Hdr, etc, with symbol 
definitions for OSFile_SaveStamped in terms of OSFile_SaveStampedW etc.

> and
> secondly, how to ensure the distribution of osf32.h (all other headers, apart
> from types.h, are regenerated on each build). I guess we could stick it
> alongside types.h, or maybe it would be best to just add the code to types.h;
> this would save the extra NEEDS.

   It shouldn't be in types.h, because logically types.h is at the "bottom" of 
the call graph. It's important not to build-in cyclic dependencies between 
components. But you are right that distribution isn't a problem: there's also 
macros.h, remember. The new files are just more of the same---the release 
script would have to be modified to know about them, and copy them to the 
release directory, as it does types.h and macros.h at present.

   So, I think we're really getting somewhere here. What do you think of that?

   PS: If we make this change, one vital thing must not be forgotten: change 
the symbol in ByteWide from os_f to os_fb, as well. Or we'll end up with some 
very serious errors!