Why are you using `std.traits.fullyQualifiedName`?

[Adam D Ruppe]

On Sunday, 22 January 2023 at 15:36:29 UTC, Atila Neves wrote:
> I use it all the time, especially since I do so much with 
> reflection.

I probably do even more with reflection, and yet have only used 
fullyQualifiedName once in all my code (and that usage could 
easily be replaced with something else; it is just an arbitrary 
key in a database).

Creating web apis and user interfaces out of D classes? No FQN.

Creating script language bindings out of arbitrary D 
declarations? No FQN.

Creating dynamic library loaders out of D interfaces? No FQN.

Creating bi-directional bridges between D and Java or C# code? No 
FQN.

Custom unittesting? No FQN.

Making maps of D modules to instantiate classes from XML files? 
No FQN.

Custom event loop message box that takes arbitrary types and 
dispatches them? No need for FQN.

I've tried to look at your mirror library, but it is almost 
entirely undocumented, which makes it difficult to evaluate. The 
only packages that use it on dub are glue-d (which has zero users 
and unmaintained for nearly three years) and autowrap, which is a 
binding generator, something I've done many times. It is not 
clear why fullyQualifiedName is necessary or in any way 
beneficial for this task.


> I need a unique name for types to store

Use .mangleof or typeid(), depending on the circumstance. That's 
what dmd and druntime do.

> to show to the user when something goes wrong

Make a partially qualified name out of the identifier, it will be 
more readable in the general case. That's what dmd does.

> to avoid name clash issues due to imports in generated code

Use local names instead and this is not a problem. If you are 
seeing clashes, that's an indication that you're fighting the 
language instead of working with it. This is often where the wins 
come from using better approaches.