www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Associating symbols with attributes (D 2.0)

reply Burton Radons <burton.radons shaw.ca> writes:
Not even the great Jarrett Billingsley has done this one? Daaaamn. Guess we
will need attributes then.
Mar 06 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Fri, Mar 6, 2009 at 4:25 PM, Burton Radons <burton.radons shaw.ca> wrote:
 Not even the great Jarrett Billingsley has done this one? Daaaamn. Guess we
will need attributes then.

Psh! Most template hacking I learned from the best - Don and Kirk :P Don't bother introspecting enums. It will give you nothing but sadness. The compiler hates enums in many ways. Perhaps .mangleof will work? You'll have to parse it out if you want a prettier name, but..
Mar 06 2009
parent reply Burton Radons <burton.radons shaw.ca> writes:
Jarrett Billingsley Wrote:

 On Fri, Mar 6, 2009 at 4:25 PM, Burton Radons <burton.radons shaw.ca> wrote:
 Not even the great Jarrett Billingsley has done this one? Daaaamn. Guess we
will need attributes then.

Psh! Most template hacking I learned from the best - Don and Kirk :P Don't bother introspecting enums. It will give you nothing but sadness. The compiler hates enums in many ways.

Works great actually. The only thing I needed to do was turn __traits (allMembers) from whatever the hell it is into an actual tuple: template memberNames (T) { mixin ("alias tuple! (" ~ (__traits (allMembers, T).stringof [1 .. $ - 1]) ~ ") memberNames;"); } This gives me the correct list of names, and those all work just fine with mixins. I was going to go with an enumeration builder function but I just can't lose autodoc.
 Perhaps .mangleof will work?  You'll have to parse it out if you want
 a prettier name, but..

No, it's a scope issue. The symbol itself is visible in that scope because it's an argument to the template, but from that point in the scope you can only reach symbols that are deeper, not further out. The only hope I could see would be for mixin expressions: template getAttributes (T, U = mixin (T.stringof ~ "_attributes")) { alias U getAttributes; } However, I have no idea how I could possibly make that work with symbols which don't have any attributes defined for them. I just ended up putting a false value in the enumeration with special meaning, which sucks.
Mar 06 2009
parent Don <nospam nospam.com> writes:
Burton Radons wrote:
 Jarrett Billingsley Wrote:
 
 On Fri, Mar 6, 2009 at 4:25 PM, Burton Radons <burton.radons shaw.ca> wrote:
 Not even the great Jarrett Billingsley has done this one? Daaaamn. Guess we
will need attributes then.

Don't bother introspecting enums. It will give you nothing but sadness. The compiler hates enums in many ways.

Works great actually. The only thing I needed to do was turn __traits (allMembers) from whatever the hell it is into an actual tuple: template memberNames (T) { mixin ("alias tuple! (" ~ (__traits (allMembers, T).stringof [1 .. $ - 1]) ~ ") memberNames;"); } This gives me the correct list of names, and those all work just fine with mixins. I was going to go with an enumeration builder function but I just can't lose autodoc.
 Perhaps .mangleof will work?  You'll have to parse it out if you want
 a prettier name, but..

No, it's a scope issue. The symbol itself is visible in that scope because it's an argument to the template, but from that point in the scope you can only reach symbols that are deeper, not further out.

If you have it in the form of an alias parameter, you can pass it deeper. The fundamental problem to solve is to turn the __traits(allMembers) into an alias tuple. I don't know if that's possible right now -- your chance of encountering compiler bugs is very high.
 
 The only hope I could see would be for mixin expressions:
 
    template getAttributes (T, U = mixin (T.stringof ~ "_attributes"))
    {
       alias U getAttributes;
    }
 
 However, I have no idea how I could possibly make that work with symbols which
don't have any attributes defined for them.
 
 I just ended up putting a false value in the enumeration with special meaning,
which sucks.

Mar 09 2009
prev sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Fri, Mar 6, 2009 at 7:26 PM, Burton Radons <burton.radons shaw.ca> wrote=
:
 Don't bother introspecting enums. =A0It will give you nothing but
 sadness. =A0The compiler hates enums in many ways.

Works great actually. The only thing I needed to do was turn __traits (al=

Oh - D2. Well that precludes my participation in this conversation entirel= y.
Mar 06 2009