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.
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:
accessandaccess constantspecifiers 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).accessandaccess constantwas 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 defineaccess constantas a subtype ofaccess? So my solution has been to define theaccess constantversion (*_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:I'd be glad to hear opinions about these options from others, specially users of ASFML, like @HonkiTonk and @Fabien-Chouteau.