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

WIP fluent generator #10

Open
wants to merge 24 commits into
base: main
Choose a base branch
from
Open

WIP fluent generator #10

wants to merge 24 commits into from

Conversation

keynmol
Copy link
Collaborator

@keynmol keynmol commented Jan 10, 2024

Closes #6

Goal

Provide idiomatic Scala bindings using regular classes, methods, traits, etc. to recover the inherently object oriented nature of gnome libraries. These bindings are called fluent.

The aim is to eliminate all mentions of scalanative.unsafe types from the bindings, by means of copying, allocations, and other things that'd make a C developer's hair stand up. As such, these bindings introduce overhead, but in most cases this should be fine. Getting unsafe backing values from fluent wrappers should be easy, to use those on the hotpath and delegate straight to C bindings.

The raw C bindings are not deprecated, just moved to internal package. They power fluent bindings, and will always be shipped in same artifact.

The code is in fluent-generator module, and you can give it a jolly good whirl by running gobject/generateFluentBindings.

At this point the goal of this PR is to

TODO:

  • throws=1 on methods manifests itself as a last parameter error: GError**, we should produce it as Either[Error, A].
  • nullable=1 on methods - should produce Option[A] as a result. May be check if that exists on parameters as well?
  • Arrays - not handled well at all. Should provide a union type option with Zone (like String | CString)
  • Virtual methods? Whatever they are
  • Ownership? Does it even make sense?
  • Traits being returned from methods - Perhaps we need an anonymous class. I think that's what will eventually make use of virtual methods - they're part of the interface I think
  • Render docs?
  • Out parameters? They have direction="out". We should change the output of a function to be a tuple with all those parameters
  • function - static methods on companion objects
  • <varargs>

@keynmol keynmol mentioned this pull request Mar 31, 2024
@keynmol keynmol marked this pull request as ready for review July 4, 2024 13:37
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

Successfully merging this pull request may close these issues.

Generate idiomatic bindings using GIR
1 participant