Add support for GType name conflict resolution via opt-in

[sdroege]

Currently if multiple versions of the gio crate are linked in, e.g. gio::ReadInputStream could be registered multiple times with the same GType name. The second one would fail with a panic.

Instead it would be useful if it could simply use ReadInputStream-1 or ReadInputStream-N as type name, i.e. count until it finds a name that is not used yet.

This has to be opt-in because in other cases the GType name is part of the API and you actually don't want this behaviour.

---

This applies to GObjects, boxed types, enums/flags, etc.

[pbor]

It seems to me that (unfortunately) the type name is always part of the API in glib. It is not very clear to me why gio Streams are called out as a special case.

[sdroege]

It seems to me that (unfortunately) the type name is always part of the API in glib.

Do you think this will cause problems in practice? This is for types where you explicitly opt in to this behaviour.

It is not very clear to me why gio Streams are called out as a special case.

It's one of the 3 types that we define inside the bindings, and where you can easily get such conflicts at runtime because of that. E.g. if two GStreamer plugins make use of it and are used in the same process.

[pbor]

Searching for g_type_from_name on github turns up more than 7K matches... my fear is that some reflection hacks based on name convention would fail.

[sdroege]

Sure, those would fail. But that seems an improvement for those types right now because right now the process would just abort :) Also note that the type name only differs once a second type with the same name is registered (and after opting in to this feature): the first one gets the proper name.

[pbor]

Abort might be better than strange behavior because code looks up a type which is more or less the same but behaves slightly differently.

I guess my question is: do we really want to start supporting multiple versions of the same crate, or will it be a slippery slope? It scares me a bit, but maybe I simply have not run into this problem to be motivated to solve it :)

I'll defer to you on the decision. I will take a look at the code in the mean time

[sdroege]

I guess my question is: do we really want to start supporting multiple versions of the same crate

We already support that, and that's how I ran into it. If you build two GStreamer plugins, then each has its own version of the bindings statically linked in. If you load both into the same process, you have twice the bindings in the process and neither knows about the other, but the GType name conflicts could break one of them.

I think this is mostly relevant for plugin situations, or e.g. writing Python modules in Rust.

[sdroege]

@pbor Does that use-case make more sense to you now? :)