Skip to content

Different options for the API: request for comments #1

@mgrojo

Description

@mgrojo

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions