Avoid reflection

[badcel]

In custom GObject subclasses we are interested in different information like ClassInit, InstanceInit static methods.

This information could be made available in some kind of SubclassDescriptor, simmilar to the TypeDescriptor as a delegate.

If the registration of types is not done via reflection but with some module initializer we can use source generators to register the GObject subclasses during compile time of our users.

We could than use the SubclassDescriptor during object creation of a type to retrieve a delegate for the ClassInit method without reflection.

[mjakeman]

While I'm fine with using source generators to reduce boilerplate, I think it's okay to have some level of reflection if it makes the API easier. Subclass registration is one of those areas where I think reflection does more good than harm, as it makes GObject integration effectively transparent to the user (and one of the biggest benefits of doing Gtk with C# is API cleanliness imo).

A particular concern I have about source generators is that they preclude us from ever supporting F#/VB. Microsoft actually advises to only use source generators to optimise rather than replace certain features, and have a reflection based alternative as a fallback:

From: https://devblogs.microsoft.com/dotnet/introducing-c-source-generators/

Do Source Generators introduce compatibility concerns for libraries?
This depends on how libraries are authored. Since VB and F# currently don’t support Source Generators, library authors should avoid designing their features such that they require a Source Generator. Ideally, features have fallbacks to runtime reflection and/or reflection emit. This is something that library authors will need to careful consider before adopting Source Generators. We expect most library authors will use Source Generators to augment – rather than replace – current experiences for C# developers

That being said, I did have an idea for getting around reflection for instance/class init. We could let the user assign the relevant methods in the static constructor, and then retrieve these later without reflection. For example:

static MySubclass()
{
    SetClassInit(typeof(MySubclass), MyClassInitFunc);
    SetInstanceInit(typeof(MySubclass), SomeOtherFunction);
}

Which then are stored in some kind of dictionary, hashset, etc (the same way we'd do it using module initialisers). This avoids a hard dependency of source generators and also keeps things within the class.

Thoughts?

[badcel]

Shouldn't doing it in the static constructor (as opposed to instance constructor) be fine?

For the current workflow yes. But if we want to be able to create the sub type indirectly through GObject? So no C# constructors are executed if the object is created at first. If we register the type beforehand in the type system with callbacks for the ClassInit and InstanceInit we should get it to work:

• If the ClassInit is received we execute the ClassInit of our sub type
• If the InstanceInit is received we can call TryWrapPointerAs which initializes our object and put's it into the cache.

Nevertheless I think we should focus one more time on the source generator and module initializer aspect.

We already made the switch to .NET5 to be able to profit from this features. But if we now merge #133 and #134 I think we should go the source generator route as good as we can. This does not mean to enforce it in all cases, like you mentioned. But our general approach would be to integrate deeply into C like with the ClassInit example from above. We execute the code the C world expects because the C world calls directly into the correct C# code avoiding reflection.

From a technical standpoint I think this is the better approach and I would go forward with it even on the expense of some (potential) users.

It looks like @na2axl is not available currently. But as he agreed on our previous discussions regarding this topic: Could you start reviewing and merging if you agree and still have some time left?

I really don't want to tackle a big new coding topic until we have settled this. So as Scriban is moving quite fast currently (@xoofx added a source nuget to improve the use case for source generators) I will try to adopt that and do perhaps some smaller things in the mean time.

[mjakeman]

Bit of a wall of text incoming, so fair warning (Also ignore the first version of this. Accidently posted mid-writing 😅).

I've had some time to go over your PRs, and I'll do a proper review tonight. I see some small stylistic issues, but I like the direction, so no problems there.

This is sort of a proposal for possible bidirectional bindings, an alternative to using module initialisers for ClassInit/InstanceInit, as well some comments about creating GObjects indirectly (and the caveats/drawbacks of doing that).

---

I think we're getting back to our earlier discussion of whether the bindings should be bidirectional, and what it's worth sacrificing to achieve this. Allowing subclasses to be created indirectly is a form of bidirectionality, so doing it properly could make types exportable to C too. See my comment in #46 for a bit more context.

But if we want to be able to create the sub type indirectly through GObject? So no C# constructors are executed if the object is created at first.

This is the big question: Do we want to support this? I'd like to, but with a few major caveats.

Firstly, I'm still not convinced we need the module initialiser for this, and I'm against using it as it contributes to the startup time of the program. For every subclass the user makes, we increase the cost of the program accordingly.

I'm also strongly for making this opt-in (maybe the user has to define an Export attribute for types they want accessible from non-managed code). This again reduces the burden of types that are never going to be used outside of managed code (e.g. all of Hyena/Banshee).

GObject uses a lazy type system, where types are only registered on the first call to my_subclass_get_type(). If we supply this method, then we can register class_init, instance_init, etc on demand (and later export it to C using .NET 5's Native Exports, although this brings up complicated questions about hosted runtimes). For non source generator users, we would make them hand-write a get type function (probably in the form of a SubclassDescriptor like you suggested), while for everyone else we can infer this at compile time - no reflection needed.

We already sort of do this, but with a one-size-fits-all get_type() method in TypeIntegration.cs#L82-L100. In addition to calling this in the constructor, we'd make it callable from a my_subclass_get_type() function exported to GObject. I think this solves the issue of registering ClassInit and InstanceInit early enough? Again, we can avoid reflection here.

(Related: https://developer.gnome.org/gobject/stable/gtype-instantiable-classed.html)

I'm not a fan of bypassing the C# constructor, as it'd be incredibly unnatural for constructor initialisation code to not be executed when the object is created. We'd need to come up with some kind of solution here that is both clear to the user and doesn't involve looping between GObject creating a managed object, and the managed object then creating another GObject. Your idea about using Object's static cache could work really well here.

If the ClassInit is received we execute the ClassInit of our sub type

No complaints here :)

If the InstanceInit is received we can call TryWrapPointerAs which initializes our object and put's it into the cache.

TryWrapPointerAs only works for Wrapper types, not for Subclasses. This is an intentional decision, as our type integration is predicated on the assumption that we will never receive a pointer to a Subclass type we didn't create on the managed side (e.g. the subclass will already exist, because we made it). We don't allow wrapping subclasses because it violates the assumption that managed subclasses 'own' their GObject.

I agree broadly with what you've proposed, but I think we need to spend some time hammering this out to make sure we get it right 👍. Again, this is a bit off-topic, and I don't have any problems with our use of source generators so far. My main concern is using source generators as a crutch for API design (I'd really like to support F#), and making sure we strike a good balance between supporting all of GObject, but also making GTK ergonomic for C# devs to use.

[badcel]

But if we want to be able to create the sub type indirectly through GObject? So no C# constructors are executed if the object is created at first.
This is the big question: Do we want to support this? I'd like to, but with a few major caveats.

I would say we try to move into a direction to support this. We just set it as our goal and try to reach it. I think currently we can't guarantee to reach it.

If we have some idea of doing the lazy class registering without reflection this would be absolutely great and I would prefer it by far over the module initializer solution.
Can you give some more detail how should the C world know where our my_subclass_get_type() method is if we don't register it beforehand somehow?

I'm not a fan of bypassing the C# constructor, as it'd be incredibly unnatural for constructor initialisation code to not be executed when the object is created.

Right. The final solution must include calling the objects constructor.

This is an intentional decision, as our type integration is predicated on the assumption that we will never receive a pointer to a Subclass type we didn't create on the managed side

I'm not saying that the code as is will work. We will need to do a lot of refactoring and rethinking to get this working (if at all). But I think we should try to reach that goal.

All the type integration is quite a complex topic and I fear that we will have very large PRs and we are discussing a lot and trying to fully grab the details but will miss out on some either way.

So my suggestions is that we just start slowly and improve the code bit by bit with smaller PRs tackling one problem at a time. We just start with the composite templates. For me all code we commit to develop now is still under heavy development. We will just iterate on and improve with the consequence that some code will probably be removed again. But if we have a great set of features and a nice codebase in the end it is worth the effort.

---

Less important remarks:

Firstly, I'm still not convinced we need the module initialiser for this, and I'm against using it as it contributes to the startup time of the program. For every subclass the user makes, we increase the cost of the program accordingly.

We could do some performance meassurings but even if we register several thousand classes at startup it should be extremly fast. If we would need to resolve the same several thousand classes via reflection I believe that it is by far slower. In case the lazy class registration is not working out we could just do some performance meassurings to check both ideas.

I'm also strongly for making this opt-in (maybe the user has to define an Export attribute for types they want accessible from non-managed code).

Sure if we have some performance issues why not 👍

My main concern is using source generators as a crutch for API design (I'd really like to support F#), and making sure we strike a good balance between supporting all of GObject, but also making GTK ergonomic for C# devs to use.

I fully agree to you here. 👍 You can quote me on this 😉

[mjakeman]

A quick response to this, will write up something more substantial later.

Can you give some more detail how should the C world know where our my_subclass_get_type() method is if we don't register it beforehand somehow?

To the best of my knowledge, this is how GObject first learns about types:

When we first start the program, GObject has no knowledge of types (until, of course, we tell it about them). For example, we have a class called ViewerFile derived directly from GObject (generic example taken from glib docs).

In order to create an instance of ViewerFile, we need to call g_object_new(), which we do as follows:

ViewerFile *viewer_file = (ViewerFile *) g_object_new (VIEWER_TYPE_FILE, ...);

The key to this working is the macro VIEWER_TYPE_FILE, which is defined as follows:

#define VIEWER_TYPE_FILE (viewer_file_get_type ())

So, when creating an object for the first time, the following steps happen:

1. VIEWER_TYPE_FILE is evaluated to viewer_file_get_type().
2. viewer_file_get_type() registers the type in the GType system, defining the class_init and instance_init functions that allow the object to be instantiated. It stores the returned type ID in a local static variable, and returns that in future (since the type is now registered).
3. viewer_file_get_type() returns the aforementioned type ID whenever it is called now.
4. g_object_new(viewer_file_get_type(), ...) now can use the type ID that was just registered to lookup the type in GType's internal dictionary, and use this to create a new instance of the type.
5. Type registration complete :)

So in our case, GObject will never need to register a type until either:

• We have already registered it ourselves, at which point the type ID is known (this is our current behaviour)
• A user writing C code calls our hypothetical Native Exported my_subclass_get_type() function, at which point we then have full control over registering the type. Since the function is generated at compile time, we know our ClassInit/InstanceInit funcs and there is no reflection penalty.

I highly recommend this page of the GObject docs. It shows how to instantiate classed types without any of the GObject convenience API, and was instrumental in learning how it works myself.

[badcel]

Thank you for clarification. This is largly what I already thought about it. I read the page you linked, too 😄 .

I just did not fully get that you want to export the viewer_file_get_type() to C so that it can be called directly from GObject. I even can't imagine that this is somehow working. But my C knowledge is quite limited especially if it comes to interop.

I found this stackoverflow article. There it looks hard for custom widgets in a UI file even for the case that the custom widget is written in C.

Do we have the possibility to somehow get into it via solution number 2 or 3? As using solution 1 would probably mean registering the type beforehand.