Re: [Hamlib-developer] Problems with 64-bit constants

[Bill S. <g4...@cl...>]

On 28/12/2018 18:22, Adrian Chadd wrote:
> Hi,
>
> I realise it's API change, but like, at some point you have to bite 
> the fact that the API can't move forward across languages and it's 
> time to change.
>
> Keep the existing one 32 bit, mark it deprecated, printf() if 
> something uses it (once per process!) and add a new variable-sized one 
> where you request capabilities by some id/tag and you get them. 
> Otherwise yeah, this dance never ends.
>
> -adrian
> (kk6vqk)
>
Hi Adrian,

unfortunately Hamlib breaks a cardinal rule of APIs and exposes data 
structures that leak implementation details into the public headers, 
that makes deprecation rather difficult. For example a deprecated 32-bit 
modes supported object (and there are several of them already) would 
have to be accessed and updated in parallel with a newer array of 32-bit 
objects (assuming that was the chosen new mechanism). If the data 
structures were hidden behind function calls then deprecation is much 
easier as the Hamlib implementation could use the new structure 
internally to back both the deprecated and new APIs (not that a 
deprecated version would be needed in this case but in future it is the 
way to go). Worst case with the current API; a client might change the 
deprecated data structure to be inconsistent with the new data structure 
- that is a mess that would require ridiculous amounts of code to keep 
straight.

IMHO, before even attempting any breaking API changes, consideration 
should be given to a new Hamlib API that does away with exposed data 
structures and makes the rig pointer an opaque handle such as a pointer 
to a forward declared struct or a void pointer (and no cheating by 
having API calls that return pointers to internal structures that are 
publicly defined and thus leak implementation details all over again). 
This very much non-trivial as good API design, that doesn't leak 
implementation details, is hard but at least having many current clients 
to the existing API helps a lot with deciding what to provide.

Of course the Lua binding issue is a small matter and dropping the Lua 
binding or some hack are probably justified since I don't see anyone 
stepping up to design a proper API for Hamlib :(

73
Bill
G4WJS.