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

Add support for GLib::String #80

Open
hugopl opened this issue Feb 27, 2023 · 1 comment
Open

Add support for GLib::String #80

hugopl opened this issue Feb 27, 2023 · 1 comment
Labels
enhancement New feature or request

Comments

@hugopl
Copy link
Owner

hugopl commented Feb 27, 2023

Meanwhile GLib::String must be transparent for Crystal users, i.e. translated to Crystal strings.

@hugopl
Copy link
Owner Author

hugopl commented Feb 27, 2023

Thinking about how to support this... I think that the handmade: configuration for types in binding.yml files must be changed.

Instead of having true/false, it could have strings that to be used for the type instead.

Consider the C function bellow:

/**
 * test_subject_concat_g_strings:
 * @str_full: (transfer full)
 * @str_none: (transfer none)
 * Returns: (transfer full)
 *
 * Used to test GLib String bindings.
 */
GString* test_subject_concat_g_strings(GString* str_full, GString* str_none);

Currently if I set the type String has handmade: true, a binding for it will be generated as bellow, note that it still use the GLib::String as return type, it just relax the parameters type restrictions, or better, delegate this to GLib::String.new, good for GValue bindings, useless for GString since we want to make it fully transparent for Crystal developers.

    def self.concat_g_strings(str_full : _, str_none : _) : GLib::String
      # Generator::HandmadeArgPlan
      str_full = if !str_full.is_a?(GLib::String)
                   GLib::String.new(str_full).to_unsafe
                 else
                   str_full.to_unsafe
                 end
      # Generator::HandmadeArgPlan
      str_none = if !str_none.is_a?(GLib::String)
                   GLib::String.new(str_none).to_unsafe
                 else
                   str_none.to_unsafe
                 end
      _retval = LibTest.test_subject_concat_g_strings(str_full, str_none)
      GLib::String.new(_retval, GICrystal::Transfer::Full)
    end

So... if instead of accept only true/false, the handmade option could accept strings to be used as the type in the generated code:

String:
    as_parameter: String
    as_return: String

So the code rendered for the function above could be:

    def self.concat_g_strings(str_full : String, str_none : String) : String
      # Generator::HandmadeArgPlan
      str_full = GICrystal.convert_glib_string_from_crystal(str_full)
      # Generator::HandmadeArgPlan
      str_none = GICrystal.convert_glib_string_from_crystal(str_none)

      _retval = LibTest.test_subject_concat_g_strings(str_full, str_none)
      GICrystal.convert_glib_string_to_crystal(_retval, :full)
    end

GICrystal.convert_glib_string_from_crystal and GICrystal.convert_glib_string_to_crystal would need to be written by the bindings author.

I'm still thinking about the side effects of this, but at a first look seems that GValue bidings can fit on this schema.

Final thoughts

I would like to see if there are other use cases for this, because GLib::String is used nowhere... so this maybe is too much effort to support a type that nobody uses instead of use my energy on something more interesting and useful for more people.

@hugopl hugopl added the enhancement New feature or request label Feb 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant