-
Notifications
You must be signed in to change notification settings - Fork 0
Description
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
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). - 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
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:
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.