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

Do not use reflection to create objects from IntPtr but SafeHandles #397

Open
badcel opened this issue Aug 7, 2021 · 2 comments · May be fixed by #1006 or #1118
Open

Do not use reflection to create objects from IntPtr but SafeHandles #397

badcel opened this issue Aug 7, 2021 · 2 comments · May be fixed by #1006 or #1118
Milestone

Comments

@badcel
Copy link
Member

badcel commented Aug 7, 2021

Currently we use reflection to create an object from an IntPtr:

ConstructorInfo? ctor = type.GetConstructor(

ConstructorInfo? ctor = type.GetConstructor(

This is necessary because the TypeDictioanry only returns our instance type for a given GType.

If we update the Native Methods in a way that they return a concrete SafeHandle instead of an IntPtr and each SafeHandle provides a method like CreateInstance this method could create the concrete instance and effectively wrap itself into an object.

Currently only records use SafeHandle. For this to work classes would need to use SafeHandles, too.

One point which is not completely solved with this is that a GValue holding a boxed type can only return an IntPtr and not a SafeHandle
In this case we can create the concrete SafeHandle (probably via reflection) and again call CreateInstance
Another possibility is that the type dictionary does carry an action which accepts an IntPtr and creates the needed SafeHandle. In This way if one has the GType and an IntPtr one could get the correct action from the type dictioanry and with this the SafeHandle, which itself can create the instance. Thus avoiding reflection alltogether.

There is a special cases for GDK Event. In this case the given type does not correlate to one class, but to many different classes / events. If we can detect this scenario during generation time, we can generate all the needed code in the safe handle.
As this code is currently not generated, we need to allow the CreateInstance method of the SafeHandle to be customizeable.

This code should get obsolete with it:

private {model.Name}(IntPtr ptr, bool ownsHandle) : this(ownsHandle

private static ConstructorInfo? GetBoxedConstructor(System.Type type)

private static MethodInfo? GetSecretFactoryMethod(System.Type type)

Hint:
Boxed types have a copy/free function pair, which can be implemented via refcounting

Update: It is not possible to rely on a safe handle which knows the C/C# types as the returned safe handle could be of type „Widget“ but the instance be of type „Button“. It is always necessary to detect the „real“ type of an instance.

@badcel badcel changed the title Do not use reflection to create objects from IntPtr Do not use reflection to create objects from IntPtr but SafeHandles Dec 19, 2021
@badcel
Copy link
Member Author

badcel commented Apr 28, 2022

Using safe handles allows to differentiate between owned and unowned handles. This would simplify the object constructor which currently requires an intptr and the information of the ptr is owned or not as a bool.

@badcel
Copy link
Member Author

badcel commented Dec 18, 2022

Alternatively it is possible with dotnet 7 to define a static interface method which creates an instance of an object.

The safehandle on the other hand could carry the information regarding it's GType and dotnet type. Meaning if we have a handle we automatically know it's type in C and dotnet world. (This does not solve the "real type" problem.)

Keep #930 in mind.

@badcel badcel linked a pull request Jan 21, 2024 that will close this issue
6 tasks
@badcel badcel added this to the 0.6.0 milestone Sep 10, 2024
@badcel badcel linked a pull request Sep 22, 2024 that will close this issue
6 tasks
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 a pull request may close this issue.

1 participant