You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 isnew tguiWidget;
I'd be glad to hear opinions about these options from others, specially users of ASFML, like @HonkiTonk and @Fabien-Chouteau.
The text was updated successfully, but these errors were encountered:
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:
access
andaccess 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).access
andaccess 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 defineaccess constant
as a subtype ofaccess
? So my solution has been to define theaccess 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:I'd be glad to hear opinions about these options from others, specially users of ASFML, like @HonkiTonk and @Fabien-Chouteau.
The text was updated successfully, but these errors were encountered: