Why are you using `std.traits.fullyQualifiedName`?
Adam D Ruppe
destructionator at gmail.com
Mon Jan 23 16:27:04 UTC 2023
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.
More information about the Digitalmars-d
mailing list