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