Font_ApplyFields problem

[David J. Ruck]

On 2 Nov 2001 "Jonathan Coxhead" <jonathan at doves.demon.co.uk> wrote:
>    We've been round this loop before, and no new points are being made.

Well I really hate to have to start this discussion again, but there are
issues that are still being misrepresented. Please read to the end before
jumping to conclusions.

>    On 2 Nov 2001, at 1:50, David J. Ruck wrote:
> 
>> On 1 Nov 2001 "Jonathan Coxhead" <jonathan at doves.demon.co.uk> wrote:
>>>    But that could never be the only version, because to support the older 
>>> versions of the OS, which have 8-bit file handles, we'd still need to 
>>> distribute the os_f functions.
>> 
>> Why? Using 32bits for file handles works on all RISC OS machines.
> 
>    But there are applications which use byte-sized variables for file
> handles,  and they'd break when relinked under your scheme.

Yes, this is the point of the phasing out for *new* versions of the library.
For old applications you have two choices:-

* Dont use the newer version of the OSLib library

or 

* Recompile using the the correct headers that map to legacy functions

>> There is no such thing as 8bit file handles, as far as the user is
>> concerned all the file API's return a 32bit opaque values, always have and
>> always will.
> 
>    No---OSLib uses byte-sized quantities for them. As you know very well!
> This  feature, though arguably a mistake, is a completely visible part of
> the exposed  API.

I am talking about the RISC OS SWI API as detailed by the PRM's, OSLib
unequivocally breaks that. The OSLib implemenation does not define the RISC
OS API, it was not even an offical Acorn product!

>    That's a documentation problem. The solution to it does not consist of 
> breaking people's perfectly good code.

You are entitled to your opinion that this is good code, however I see it as
fundementally flawed code being perpetuated adfinitum. 

>    Right. This is why we have the -W variants. I'm surprised you care even 
> slightly about the 8-bit variants---as long as you don't use them, they do
> you  no harm. Your argument seems to be "I don't use them, and no-one else
> should be  allowed to either."

No, the proposal now is that the 8bit functions are retained but renamed with
a postfix that making them clearly identifyable as depreciated legacy
interfaces, and the 32bit 'W' variants become the default. A compatibility
header would be provided to map on to these new names, for those that really
must retain 8bit handles for whatever arcane and almost certainly invalid
reasons. 

>    Anyway, all this has been hashed through at great length already. I see
> no  reason to change any of our previous conclusions.

Hardly a constructive or forward looking argument, especially in the light
that other people who previously supported the stalemate position are now
considering alternatives.

Cheers
---Dave

-- 
____________________________________________________________________________

  David J. Ruck    Phone: +44- (0)7974 108301    Email: druck at freeuk.com
____________________________________________________________________________