glib: Decouple ObjectInterface impl from interface class struct

[felinira]

This makes ObjectInterface and ObjectSubclass more similar to each other and allows for cleaner separation between the unsafe ffi code and rust implementation.

There is some bikeshedding left to be done: InterfaceClassStruct is quite clumsy, but reusing ClassStruct is not possible, as it is tailored towards object subclasses. We could call it InterfaceStruct to align it with IsClass ->IsInterface and similar traits that omit Class. Then we should also name ObjectInterface::Class ObjectInterface::Interface I suppose.

Do we need something like glib::subclass::basic::ClassStruct for InterfaceClassStruct? I would say we don't, as most interfaces define vfuncs anyway.

Closes #1382

[sdroege]

InterfaceClassStruct is quite clumsy, but reusing ClassStruct is not possible, as it is tailored towards object subclasses. We could call it InterfaceStruct to align it with IsClass ->IsInterface and similar traits that omit Class. Then we should also name ObjectInterface::Class ObjectInterface::Interface I suppose.

Yes I think that makes sense, both. Having the word class in the context of interfaces is just confusing, even if some GObject API calls it like that (g_type_class_peek() etc)

Do we need something like glib::subclass::basic::ClassStruct for InterfaceClassStruct? I would say we don't, as most interfaces define vfuncs anyway.

I think that would be nice, especially as it's just a bit of copy&paste. It is probably not useful often, but if you do a signals/properties-only interface then this would make it a bit less code to write (there are some such interfaces!).

[felinira]

Do we need something like glib::subclass::basic::ClassStruct for InterfaceClassStruct? I would say we don't, as most interfaces define vfuncs anyway.

I think that would be nice, especially as it's just a bit of copy&paste. It is probably not useful often, but if you do a signals/properties-only interface then this would make it a bit less code to write (there are some such interfaces!).

Alright, that apparently also needs an addition to ObjectInterfaceType then to define a GlibType and GlibClassType?

[sdroege]

Alright, that apparently also needs an addition to ObjectInterfaceType then to define a GlibType and GlibClassType?

Also a good thing to make more consistent between interfaces and classes I guess :) GlibInterfaceType though.

For classes I used those associated types elsewhere in the past too so it might also become useful for something else.

[felinira]

Maybe it makes sense to handle this separately. Interfaces can also inherit from other interfaces, so we can't just assume GTypeInterface. We'd also need access to the public type, so I guess ObjectInterface also needs a Type and ParentType. This is all a bit much to add in one go IMO.

[sdroege]

Interfaces can also inherit from other interfaces, so we can't just assume GTypeInterface

Is that so? :exploding_head: I thought that worked differently via the prerequisites.

I'm fine with keeping this for a separate PR in any case. Don't have to do everything at once.

[felinira]

Is that so? 🤯 I thought that worked differently via the prerequisites.

You are right. I stared at GType for too long.

[sdroege]

But now I'm wondering if that could actually be made to work :rofl:

[sdroege]

@felinira Should we get this in then or do you want to change more as part of this PR? The boxed copy of the struct and the simple generic interface struct can also be done separately, don't really have to entangle it all and this here is IMHO complete and good as it is.

[felinira]

@felinira Should we get this in then or do you want to change more as part of this PR? The boxed copy of the struct and the simple generic interface struct can also be done separately, don't really have to entangle it all and this here is IMHO complete and good as it is.

I won't mind getting this in now. I opened #1389 to track the remaining bits.

[sdroege]

Let's do that then :)