Thread overview
Proposal for __traits
Aug 22, 2007
davidl
Aug 22, 2007
Leonard Dahlmann
Aug 22, 2007
Robert Fraser
Aug 23, 2007
Bill Baxter
Aug 23, 2007
Robert Fraser
Aug 24, 2007
Charles D Hixson
Aug 22, 2007
Bill Baxter
August 22, 2007
__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/
August 22, 2007
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.
August 22, 2007
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.
August 22, 2007
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
August 22, 2007
Jari-Matti Mäkelä 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
August 22, 2007
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 :-).
August 23, 2007
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.
August 23, 2007
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.

August 24, 2007
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.)