Permalink
Reply
On Saturday, 3 July 2021 at 16:08:59 UTC, Stefan Koch wrote:
>On Saturday, 3 July 2021 at 15:46:07 UTC, Alexandru Ermicioi wrote:
>On Saturday, 3 July 2021 at 11:59:03 UTC, Stefan Koch wrote:
>Good Day D Community,
...
Please let me know what you think.
Hi, any thoughts, on integrating core.reflect with typeinfo classes?
Seems like, right place for reflection information to be stored.
Also any plans on providing a good interface for invoking functions and class members?
Would be nice to have two sets of functionality, one for compile time, and one at run time.
Best regards,
Alexandru.
typeinfo is a failed experiment in my opinion which has never been useful and this is why I am working on core.reflect.
Why do you think it is a failed experiment?
From the looks of it reflection info you're designing has perfect place: TypeInfo. Of course, current type info architecture might not be satisfactory, but with some improvements it can accommodate core.reflect functionality.
It's true, type info seems half finished thing, but for features it already provides it is quite useful, which mainly is type identification at runtime. For example my pet project aedi which is a dependency injection container, boxes all managed components and erases their type when stored in a container. If an user wants a component out of container, it will check whether the desired component matches the type client expects by doing a typeinfo equality check, and if not throw an exception.
>The functionality for runtime and for compile time (as far as working with reflection classes in concerned) should be the same.
So say given a name of a method as string and an instance of a class that has that method at runtime (not ctfe) will I be able to call that said method on the instance?