www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 4476] New: __traits for more kinds of names

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4476

           Summary: __traits for more kinds of names
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: bearophile_hugs eml.cc


--- Comment #0 from bearophile_hugs eml.cc 2010-07-16 16:44:36 PDT ---
This is relative to page 22 of The D Programming Language.

This piece of D2 code shown in the book instantiates a class defined inside the
current module named stats:
Object.factory("stats." ~ arg);

Generally in code it's better to apply the DRY principle, avoiding to duplicate
information that later can get out of sync (in this case a change in the module
name breaks the code inside the module).

This currently works (dmd v2.047), but it's not nice, and performs run-time
computations for something that is known statically (maybe there are already
better ways to do it):

Object.factory(split(to!string({class C {}; return new C;}()), ".")[0] ~
".Foo");

The problem can be solved with few traits, able to tell at compile-time:
__traits(thisModuleName) : the name of the current module.
__traits(thisStructName) : the name of the current struct (where this line is
contained), useful to create its toString that shows the struct name too.
__traits(thisClassName) : the name of the current class (this can be found with
this.classinfo.name, but there is no need to compute it at runtime).
__traits(thisFunctionName) : the name of the current function, useful for CTFE
& string mixins.

Possibly there are already ways to find such strings at compile-time, but
having a simple standard way to do it is good (better than having magic
variables like __function_name__). Some more power of static introspection can
be very useful in D.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 16 2010
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4476


Heywood Floyd <soul8o8 gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |soul8o8 gmail.com


--- Comment #1 from Heywood Floyd <soul8o8 gmail.com> 2010-07-16 19:31:51 PDT
---
Just another workaround/hack:

module modulename;
class C{}
void main(){
    Object obj = Object.factory(.stringof[7..$] ~".C");
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 16 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4476


Gor Gyolchanyan <gor boloneum.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gor boloneum.com


--- Comment #2 from Gor Gyolchanyan <gor boloneum.com> 2011-07-28 08:08:18 PDT
---
(In reply to comment #0)
 This is relative to page 22 of The D Programming Language.
 
 This piece of D2 code shown in the book instantiates a class defined inside the
 current module named stats:
 Object.factory("stats." ~ arg);
 
 Generally in code it's better to apply the DRY principle, avoiding to duplicate
 information that later can get out of sync (in this case a change in the module
 name breaks the code inside the module).
 
 This currently works (dmd v2.047), but it's not nice, and performs run-time
 computations for something that is known statically (maybe there are already
 better ways to do it):
 
 Object.factory(split(to!string({class C {}; return new C;}()), ".")[0] ~
 ".Foo");
 
 The problem can be solved with few traits, able to tell at compile-time:
 __traits(thisModuleName) : the name of the current module.
 __traits(thisStructName) : the name of the current struct (where this line is
 contained), useful to create its toString that shows the struct name too.
 __traits(thisClassName) : the name of the current class (this can be found with
 this.classinfo.name, but there is no need to compute it at runtime).
 __traits(thisFunctionName) : the name of the current function, useful for CTFE
 & string mixins.
 
 Possibly there are already ways to find such strings at compile-time, but
 having a simple standard way to do it is good (better than having magic
 variables like __function_name__). Some more power of static introspection can
 be very useful in D.
Ha(In reply to comment #1)
 Just another workaround/hack:
 
 module modulename;
 class C{}
 void main(){
     Object obj = Object.factory(.stringof[7..$] ~".C");
 }
.stringof[7..$] is a 100% guarantee to get the module name, but if the module name coincides with anything inside it, problems will occur: module main; struct S { } void main() { mixin(`alias `~.stringof[7..$]~`.S MyStruct;`); // ERROR: function main does not have a struct in it } What i suggest is to have traits to get the aliases for the current module and current function. the current struct and class can be taken by typeof(this) and typeof(this).stringof. Thus the current function name will be accessible through __traits(thisFunction).stringof. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 28 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4476



--- Comment #3 from bearophile_hugs eml.cc 2012-01-30 17:44:25 PST ---
Another useful __traits is to find all classes in the given/current module.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 30 2012