I give up! I tried to create a reflection library but D's traits are just too screwed up!

[Alex]

On Wednesday, 3 April 2019 at 10:08:14 UTC, drug wrote:
> On 03.04.2019 12:35, Alex wrote:
>> On Wednesday, 3 April 2019 at 09:24:23 UTC, Atila Neves wrote:
>>> On Wednesday, 3 April 2019 at 07:22:10 UTC, Alex wrote:
>>>
>>>> But D's type system is too screwed up. Fields and members 
>>>> are not treated as types in and have themselves so
>>>
>>> I don't know what this means.
>> 
>> One cannot pass a field type around like one can a class. 
>> Using Fields and FieldsNameTuple does not create a type. This 
>> then requires one trying to exact the type info by hacking 
>> which then requires all kinds of tricks that never ultimately 
>> succeed. If they do work in one aspect they completely 
>> breakdown in another.
>> 
>> The BaseReflection class should is supppose to encapsulate 
>> getting the name, id, module, etc of any base reflected type. 
>> Works fine for aggregates...
>> The moment you try to use it on a field it fails because 
>> fields don't have a type. Specializing for fields then sends 
>> one off in a different direction and it fail fails.
>> 
>> I posted all the code for you. It should not be difficult to 
>> understand and get working with your knowledge about D's meta 
>> system.
>> 
>> Simply put the different code snippets in their appropriate 
>> modules and run. It should work. Note the output and the 
>> fields and methods section.
>> 
>> Now try to get the code to fill in the appropriate data for 
>> them. That is all. It should be an easy task, right? (I have 
>> specialized for the fields by hacking but the private bug 
>> stops it from being general enough)
>> 
>
> IIUC, the reason is that there are three types of data that 
> frontend operates on - Types, Symbols and Expressions. Symbols 
> and Expressions are often used together, so we have two kinds 
> in fact - Types and Symbols+Expressions. Types processing 
> differs from Symbols processing so we have this issue you have 
> encountered - Types do not have protection, for example. You 
> need to check if the entity you worked with is Types or Symbols 
> and process it accordingly.

The problem is that some of the traits do not use either types or 
symbols but strings... or they are split in to the two different 
camps without an easy way to connect them...

Again, I've given the code, it is not hard. There is a 
cFieldsReflection class, in that class one must fill out the 
info. Try it, you will find it is impossible to get anything to 
work correctly and generically. Things can be hacked to some 
degree... with methods it is even harder.

And things are not uniform so one has to make special cases. For 
example. The base class gets the basic common info, but it fails 
to be callable for fields, if you make it work for fields it will 
fail for aggregates... and so it requires creating two separate 
pathways to handle essentially the same "types" in the language.

These things should be very simple to do but they are not. I had 
no problem getting the code working for aggregates and everything 
worked as expected. Functions also were not a problem... but 
fields and methods are impossible or there documentation is 
invalid or there is some other traits that works.

Anyone claiming it is simple has the full code and it shouldn't 
take but minutes to demonstrate it working. One can give 
simplified test cases that work but then in a real application 
they fail so they are actually invalid.