-
Notifications
You must be signed in to change notification settings - Fork 7
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
Take argument type for GTypeInstance argument from argument value on SCM procedure invocation #104
Comments
OK. If I understand this correctly, in C normally one would just cast an GAsyncResult to a GTask with baker_bake_cake_finish (Baker *self,
GAsyncResult *result,
GError **error)
{
g_return_val_if_fail (g_task_is_valid (result, self), NULL);
return g_task_propagate_pointer (G_TASK (result), error);
} So the problem here is the lack of an introspected method to cast |
Yep.
Well, that's not wrong, but I wouldn't call it a 'workaround'. Rather, I'd argue that having to use |
…sion * src/gig_argument.c (c_interface_to_scm, c_object_to_scm): query type from pointer
I think that commit fixes. I'll close after I write appropriate tests. |
Thanks! I might also point out that |
* Makefile.am: add test/task.scm * test/task.scm: new <GTask> tests
* src/gig_argument (child_type): new helper (c_interface_to_scm, c_object_to_scm, c_variant_to_scm) (c_param_to_scm): prefer self-reported types
* src/gig_argument (child_type): new helper (c_interface_to_scm, c_object_to_scm): prefer self-reported types
@Bob131 implied that there are other types beyond objects/interfaces that should be handled, but, looking at how arguments get dragged through the two-step FFI->C->SCM and back again, I think only GObjects/GInterfaces can carry their own type information through that process, because the type lives within their C pointer. GBoxed could be a possibility here, where a GBoxed pointer becomes a naked C pointer through the SCM->C->FFI->C->SCM I suppose one could do a bit of a hack in But is this a real or theoretical issue? I don't know. |
Uh, well, there are varying degrees of 'real' ;) All They're generally a pain in C and not really supported by most language bindings (in my experience, anyway), but Vala makes it dead-easy to create new It's probably plenty safe to exclude support for it, I only really mention it because it used to be a pain-point and people usually were surprised to learn about said functionality. |
@ebassi from GTK says the future of GTK should just be GObject or GBoxed, and that if it is GBoxed, it should have no class hierarchy, in his blog article on type instances . So I'll take that as evidence that my laziness here is justified, and close the issue. |
The following situation cropped up writing some async code: A procedure is passed to
g_task_new()
as the callback. When the task is marked as returned the callback is invoked with theGTask
instance as an argument; however, guile-gi produces a GOOPS instance of type<GAsyncResult>
(per the GI metadata) which cannot be used with any of the<GTask>
methods.For reference, PyGObject instead constructs a new
PyObject
using the argument'sGType
(see here)The text was updated successfully, but these errors were encountered: