Overloads not returning appropriate info. [Field reflunkory]

Alex AJ at gmail.com
Sun Apr 7 03:47:25 UTC 2019


On Saturday, 6 April 2019 at 13:03:31 UTC, Adam D. Ruppe wrote:
> On Saturday, 6 April 2019 at 12:20:28 UTC, Alex wrote:
>> static foreach (f; typeof(__traits(getOverloads, T, m)))
>
> Why are you using typeof here?

I don't know, I want to say I copied that code from somewhere but 
it might have been a left over or when I was trying to get the 
code to work. Since it partially worked(notice that it "works" 
and only gives the errors in parameters).

>> probably 90% of the mixins are of the form
>>
>> mixin(`Protection = __traits(getProtection, 
>> (`~T.stringof~`).`~name~`);`);
>
>
> Try following this rule:
>
> NEVER use .stringof.

rules are meant to be broken. As I mentioned in the other post it 
doesn't help when writing the mixin as a pragma to inform one of 
the actual type being used.

I'd say the rule is actually crap because of this(if debugging 
mixins and meta code had more support it might be a good rule but 
it's very helpful to know the type. Sure we can add a pragma(msg, 
T) but sometimes I just replace mixin( with pragma(msg, and I 
want something more than it display T. I want to see the full 
string to make sure it is formatted correctly what what is being 
used for T.

What you need to tell me is why using .stringof is bad. You have 
simply conjured up a rule and are stating it but not giving any 
reason why it is not a good idea to follow when, in fact, not 
following can be shown to be beneficial.

You can't expect to lead by authority. Give a good reason why I 
should avoid it and change my current ways and I will. Just 
telling me to do it won't change my mind.

The only reason I can see why it is a good rule is that one 
doesn't have to use T.stringof when they can just use T directly, 
making the code a little easier to read.

But I've pointed out that T.stringof has it's use when viewing 
the mixin as a string, which overrides your rule if the only 
reason is it's not technically needed.

See, it might just be your own bias that makes you not like it 
when in reality it might not matter either way. So far it seems 
it is your bias but I hope you have a good objective reason why 
as it would same a few characters in typing. A good reason is "It 
breaks the compiler in these cases" or "It causes this problem 
here when you do this".

If it's just about code readability then I will keep using them 
and maybe when I get the code in to shape I will try to format it 
to take them out. But in that case you have to learn to accept 
them in prototyping because then they are useful for 
mixin->pragma(msg,






>> Protection = __traits(getProtection, T.name);
>
> But (unless T.name is private; this is a design flaw in 
> __traits(getProtection)),
>
> __traits(getProtection, __traits(getMember, T, name))
>
> will work.

Ok, so I used it and it got rid of one error where I get the 
protection.


I still get a protection issue for a private field using this 
code though:

mixin(`static foreach(a;  __traits(getAttributes, T.`~name~`)) 
Attributes ~= sAttributeReflection(to!string(a), 
typeof(a).stringof);`);

So it seems like the same design flaw exists? Have any work 
arounds for that?


Thanks for your help!



More information about the Digitalmars-d-learn mailing list