Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Different options for the API: request for comments #1

Open
mgrojo opened this issue Mar 3, 2024 · 0 comments
Open

Different options for the API: request for comments #1

mgrojo opened this issue Mar 3, 2024 · 0 comments

Comments

@mgrojo
Copy link
Owner

mgrojo commented Mar 3, 2024

In this binding, I'm following a similar approach as with ASFML, most of the functions are imported directly, and only those with strings are wrapped with a thicker version. I still have to decide about the access types used by the binding; there are two options:

  • Leave the access and access constant specifiers as generated by the compiler (this is already on the main branch). But I feel that using named types is more readable and easier to use (see next).
  • Do the same as ASFML, change the access parameters by named access types (this is implemented on branch access-types-api branch). In ASFML the difference between access and access constant was lost, and I was not entirely satisfied. But if I defined named types for both of this, conversions between the two have to be used, which seems unnatural. In fact, is it not possible to define access constant as a subtype of access? So my solution has been to define the access constant version (*_Cons) as just a subtype (without adding constraints) of the general access types (*_Ptr).

Another question is whether to apply type derivation to the widget types, since all of them are the same type in the C binding (tguiWidget), but they were thought to be put in a class hierarchy in upper bindings as in the .Net one, of the same author. I wonder if adding plain-old Ada 83 type derivation would be useful without needing to make a thicker binding with tagged types, like:

type tguiButton is new tguiWidget;

I'd be glad to hear opinions about these options from others, specially users of ASFML, like @HonkiTonk and @Fabien-Chouteau.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant