www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Proposal for __traits

reply davidl <davidl 126.com> writes:
__traits itself is great
though i think adding some builtin properties for class would be nicer

consider

class D
{
     this() { }
     ~this() { }
     void foo() { }
     int foo(int) { return 0; }
}

D.members[] ->  
"_ctor","_dtor","foo","print","toString","toHash","opCmp","opEquals"


myclass.allmembers[] -> "i","j"

class D
{
     this() { }
     ~this() { }
     void foo() { }
     int foo(int) { return 0; }
}

D.allmembers.derived[] -> "_ctor","_dtor","foo"

class D
{
     this() { }
     ~this() { }
     void foo() { }
     int foo(int) { return 2; }
}

D.allmembers.VirtualFunctions[] -> ["foo":void delegate (),"foo":int  
delegate(int)]

getVirtualFunctions could be something developed by meta programming

struct S
{
     int mx;
     static int my;
}

S.members["mx"] = 3;		// this looks nicer, but we need to extend our type  
struct of members, typeof for members is a bit strange

also final functions , abstract functions could be some sub properties



-- 
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
Aug 21 2007
next sibling parent reply Leonard Dahlmann <leo.dahlmann gmail.com> writes:
davidl Wrote:

 __traits itself is great
 though i think adding some builtin properties for class would be nicer
That's basically a nice idea. The problem with that though is, that the properties would need to be available at both compile time and runtime. IMO, RTTI is bloated enough like it is now. With __traits the user can decide if he want's these type informations to be available at runtime or not.
Aug 22 2007
next sibling parent reply Jari-Matti =?ISO-8859-1?Q?M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Leonard Dahlmann wrote:

 davidl Wrote:
 
 __traits itself is great
 though i think adding some builtin properties for class would be nicer
That's basically a nice idea. The problem with that though is, that the properties would need to be available at both compile time and runtime.
Why do they have to be available at runtime? Is e.g. mystruct.tupleof available at runtime? I think a greater problem appears because of symbol collisions. Still, I wouldn't mind having metaproperties instead of __something.
Aug 22 2007
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Jari-Matti Mkel wrote:
 Leonard Dahlmann wrote:
 
 davidl Wrote:

 __traits itself is great
 though i think adding some builtin properties for class would be nicer
That's basically a nice idea. The problem with that though is, that the properties would need to be available at both compile time and runtime.
Why do they have to be available at runtime? Is e.g. mystruct.tupleof available at runtime? I think a greater problem appears because of symbol collisions. Still, I wouldn't mind having metaproperties instead of __something.
I'd say there's a shot the '__' will disappear eventually. As I understand it the double-underscore is supposed to mean "this is experimental". -- Chris Nicholson-Sauls
Aug 22 2007
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Leonard Dahlmann Wrote:

 That's basically a nice idea. The problem with that though is, that
 the properties would need to be available at both compile time
 and runtime. IMO, RTTI is bloated enough like it is now.
How different our viewpoints are... I've been campaigning for runtime reflection for a while now, and you're against it :-).
Aug 22 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Robert Fraser wrote:
 Leonard Dahlmann Wrote:
 
 That's basically a nice idea. The problem with that though is, that
 the properties would need to be available at both compile time
 and runtime. IMO, RTTI is bloated enough like it is now.
How different our viewpoints are... I've been campaigning for runtime reflection for a while now, and you're against it :-).
I'm opposed to a mandatory, global fully dynamic runtime reflection mechanism because I believe it will lead to tremendous bloat in exe sizes (c.f. Stroustrup's example where adding reflection to some app led to 16x increase in memory usage). If it can be shown that the *bloat* in runtime resource usage won't happen, then I'd be in favor. Otherwise I think compile-time only makes sense. That way, only the things you actually use have to be included by the compiler. While it might be nice to be able to say: char[] cat = read_category_from_user(); char[] classname = read_class_name_from_user(); auto a = __traits(cat, classname); that would mean that all possible reflection info for all types must be kept in the exe. With a compile-time mechansim you can selectively make the info you want available at runtime, but it's not mandatory. class D { this() { } ~this() { } void foo() { } int foo(int) { return 0; } static char[][] allMembers() { return __traits(allMembers, typeof(this)); } } Voila! Now the allMembers info is available at runtime[1] for class D, And the compiler is free to leave out all the rest of the reflection info that you weren't planning on using anyway. And you can of course easily stick that and other functions in a template to use as a mixin. Everybody wins[2]. --bb [1] the above code probably won't work due to lack of const and whatnot, but you get the idea. [2] Except people who want to do arbitrary runtime reflection on unknown code loaded from a dll at the expense of lots of memory bloat.
Aug 22 2007
parent Robert Fraser <fraserofthenight gmail.com> writes:
How about some kind of modifier that can be applied to a type to export
additional RTTI?

Bill Baxter Wrote:

 Robert Fraser wrote:
 Leonard Dahlmann Wrote:
 
 That's basically a nice idea. The problem with that though is, that
 the properties would need to be available at both compile time
 and runtime. IMO, RTTI is bloated enough like it is now.
How different our viewpoints are... I've been campaigning for runtime reflection for a while now, and you're against it :-).
I'm opposed to a mandatory, global fully dynamic runtime reflection mechanism because I believe it will lead to tremendous bloat in exe sizes (c.f. Stroustrup's example where adding reflection to some app led to 16x increase in memory usage). If it can be shown that the *bloat* in runtime resource usage won't happen, then I'd be in favor. Otherwise I think compile-time only makes sense. That way, only the things you actually use have to be included by the compiler. While it might be nice to be able to say: char[] cat = read_category_from_user(); char[] classname = read_class_name_from_user(); auto a = __traits(cat, classname); that would mean that all possible reflection info for all types must be kept in the exe. With a compile-time mechansim you can selectively make the info you want available at runtime, but it's not mandatory. class D { this() { } ~this() { } void foo() { } int foo(int) { return 0; } static char[][] allMembers() { return __traits(allMembers, typeof(this)); } } Voila! Now the allMembers info is available at runtime[1] for class D, And the compiler is free to leave out all the rest of the reflection info that you weren't planning on using anyway. And you can of course easily stick that and other functions in a template to use as a mixin. Everybody wins[2]. --bb [1] the above code probably won't work due to lack of const and whatnot, but you get the idea. [2] Except people who want to do arbitrary runtime reflection on unknown code loaded from a dll at the expense of lots of memory bloat.
Aug 22 2007
prev sibling parent Charles D Hixson <charleshixsn earthlink.net> writes:
Robert Fraser wrote:
 Leonard Dahlmann Wrote:
 
 That's basically a nice idea. The problem with that though is, that
 the properties would need to be available at both compile time
 and runtime. IMO, RTTI is bloated enough like it is now.
How different our viewpoints are... I've been campaigning for runtime reflection for a while now, and you're against it :-).
I'd like that too, but it seems to be the minority viewpoint. If it could reasonably be implemented with a compiler switch I doubt that many would be against it, but CAN it? (I couldn't guess.) FWIW, this is one reason that I'm so glad to see the Pyd project. It's a totally different language, but it should allow me to merge run-time code with fast executing code. (Or, of course, I could mingle Python with C as an alternative... but I dislike C. Despite that I'm currently slogging through learning C+Gtk. I can call C from D. I could probably call Gtk from D...but I'm not sure about managing the callbacks. Still, C can sit in the middle and talk to D & Gtk & Python. If only it didn't involve so much dangerous use of pointers.)
Aug 23 2007
prev sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
davidl wrote:
 __traits itself is great
 though i think adding some builtin properties for class would be nicer
 
 consider
 
 class D
 {
     this() { }
     ~this() { }
     void foo() { }
     int foo(int) { return 0; }
 }
 
 D.members[] -> 
 "_ctor","_dtor","foo","print","toString","toHash","opCmp","opEquals"
 
 
 myclass.allmembers[] -> "i","j"
 
 class D
 {
     this() { }
     ~this() { }
     void foo() { }
     int foo(int) { return 0; }
 }
 
 D.allmembers.derived[] -> "_ctor","_dtor","foo"
 
 class D
 {
     this() { }
     ~this() { }
     void foo() { }
     int foo(int) { return 2; }
 }
 
 D.allmembers.VirtualFunctions[] -> ["foo":void delegate (),"foo":int 
 delegate(int)]
 
 getVirtualFunctions could be something developed by meta programming
 
 struct S
 {
     int mx;
     static int my;
 }
 
 S.members["mx"] = 3;        // this looks nicer, but we need to extend 
 our type struct of members, typeof for members is a bit strange
 
 also final functions , abstract functions could be some sub properties
That would steal a lot of possible member names from structs/classes and would mean you couldn't introduce new traits without potentially clashing with symbols in people's code. How about using D.traits.<element> or D.__traits.<element> instead? But once you do that it's really just a small cosmetic difference between that and __traits(D,<element>). --bb
Aug 22 2007