Font_ApplyFields problem

[Tony van der Hoff]

On 30 Oct 2001, in message <001601c16172$044b6320$5fec86d9 at oemcomputer>,
"Kevin Bracey" <kevin at bracey-griffith.freeserve.co.uk> wrote:

[snip]
> > > Oh, and can I add a vote for getting rid of all those horrible W
> functions?
> > > At a minimum can we have something that we can #define (or not #define)
> > > to make os_f 32-bit and get rid of them?
> > > 
> > 
> > What, in particular, do you find so objectionable to the W functions?
> 
> Practically speaking I think that it's that they break the uniform SWI name
> -> function name convention, so I have to remember to stick all the 'w's
> on. Philosophically, it's that the burden is placed on authors who want
> correct behaviour rather than those who need backwards compatibility.
> 
Yes, well, that's the dowside of the *promise* that OSLib gives: Wherever
possible, backward compatibility *will* be maintained. There are plenty of
upsides to this policy :-)

> I'm also not so convinced that backwards compatibility can be said to be
> such a dominant consideration for a statically linked library.
> 
The problem is that of users re-linking binary object code for which either
the source is unavailable (e.g. 3rd party libraries), or lost. Linking an old
module against a new OSLib would be disasterous. There are plenty of
arguments why people who try this should get all they deserve, but we, the
OSLib developers, try to avoid such issues.

> My personal ideal would be 32-bit file handles being os_f and no suffix,
> and 8-bit handles being os_f8 and with an 8 suffix (say).
> 
> > I personally believe each religion has its validity, and for better or
> > worse a decision was taken in favour of the compatibility retainers, much
> > to the chagrin of the compatibility predictors. The argument could have
> > continued for ever, and flares up every now and again, as here.
> > 
> 
> :) I was just adding my voice to the voting. You should be keeping a tally
> somewhere :)
> 
OK, I have just reviewed the OSLib-user archives for March/April 2000, when
the discussion took place.

There were essentially only 6 people who joined the fray. I believe that Dave
Ruck and John Tytgat felt the same way as you, whilst Jonathan, myself, and
Richard van der Hoff argued in favour of retaining compatibility. Dan Ellis,
I believe, went further in suggesting that we adopt OS_FW, and get rid of
OS_F in order to force people to update source code to use the 32-bit
handles.

I say 'I believe' above, because it is my interpretation of some
lengthy phiosophical discussions, wich became somewhat muddied at times.
Comments from other users were invited, but none were forthcoming, indicating
that no-one else considered it a big deal. Or maybe it got too emotional?

So with your vote, the score is 4-3 in favour of OS_FW ;-)

[snip]
> 
> The other alternative is two totally separate builds. Maybe run the DefMod
> files themselves through the a preprocessor to create the two systems.
> 
I already have 2 different builds: OSLib and OSLib32. I don't relish the idea
of maintaining 4 variants, given that a full build takes about 6 hours here
;-)

I don't think we can, at present, get rid of the W functions; there
is too much danger in retaining the non-w functions with a different
interface. 

However, given that we've now had a 18 month transitional period, what would
users think of my renaming the 8-bit functions and handles as you suggest,
thus allowing people to implement the old names as functions or macros in
their own code, for which they can take responsibility?

-- 
Tony van der Hoff         | MailTo:tony at mk-net.demon.co.uk
                          | MailTo:avanderhoff at iee.org
Buckinghamshire, England  | http:www.mk-net.demon.co.uk