www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Yet another "compile-time reflection revisited" proposal

reply "RivenTheMage" <riven-mage id.ru> writes:
*1) Replace all symbol-related traits with ".metainfo" property*

__traits(isAbstractClass, A) ==> A.metainfo.isAbstractClass

__traits(A.func, isVirtualFunction) ==> 
by name: A.metainfo.members["func"].isVirtualFunction
by index: A.metainfo.members[N].isVirtualFunction

__traits(hasMember, A, "func") ==> A.metainfo.members.find("func")

Aliasing should be posssible:
---
alias A.metainfo.members mymeta;
mymeta.find("func");
---


*2) Replace rest of traits with "meta" keyword*

__traits(compiles, ...) ==> meta.compiles(...)


*4) Add special extendable namespace, accesible through "meta" keyword*

The namespace can be extented by special file "meta.d" which should be a part
of D runtime. Actually, it's the same thing as std.traits, the intention is
to put all reflection stuff under one roof.

instead of:
---
import std.traits; 
int foo(); 
ReturnType!(foo) x;
---

it would be:
---
int foo();
meta.ReturnType!(foo) x;
---


*6) Replace identificator-related "is" expressions with ".metainfo" property*

is(Identifier ...) ==> Identifier.metainfo.isXXX(...)


*7) Replace rest of "is" expressions with "meta.is"*

is(...) ==> meta.isXXX(...)


*5) Replace "typeid" keyword with ".typeinfo" property*

typeid(int) ==> int.typeinfo
typeid(typeof(x)) ==> typeof(x).typeinfo
typeid(i++) ==> (i++).typeinfo


Thoughts?
Nov 29 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-11-29 21:11, RivenTheMage wrote:

 *1) Replace all symbol-related traits with ".metainfo" property*

 __traits(isAbstractClass, A) ==>  A.metainfo.isAbstractClass

 __traits(A.func, isVirtualFunction) ==>
 by name: A.metainfo.members["func"].isVirtualFunction
 by index: A.metainfo.members[N].isVirtualFunction

 __traits(hasMember, A, "func") ==>  A.metainfo.members.find("func")

 Aliasing should be posssible:
 ---
 alias A.metainfo.members mymeta;
 mymeta.find("func");
 ---


 *2) Replace rest of traits with "meta" keyword*

 __traits(compiles, ...) ==>  meta.compiles(...)


It would be good if "compiles" could be a block, but that would be 
inconsistent with the rest. Something like this:

meta.compiles
{
     // code
}


 *4) Add special extendable namespace, accesible through "meta" keyword*

 The namespace can be extented by special file "meta.d" which should be a part
 of D runtime. Actually, it's the same thing as std.traits, the intention is
 to put all reflection stuff under one roof.

 instead of:
 ---
 import std.traits;
 int foo();
 ReturnType!(foo) x;
 ---

 it would be:
 ---
 int foo();
 meta.ReturnType!(foo) x;
 ---


This would basically implicitly import meta.d, like object.di? Would it 
be possible to extend somehow for a user?


 *6) Replace identificator-related "is" expressions with ".metainfo" property*

 is(Identifier ...) ==>  Identifier.metainfo.isXXX(...)


 *7) Replace rest of "is" expressions with "meta.is"*

 is(...) ==>  meta.isXXX(...)


 *5) Replace "typeid" keyword with ".typeinfo" property*

 typeid(int) ==>  int.typeinfo
 typeid(typeof(x)) ==>  typeof(x).typeinfo
 typeid(i++) ==>  (i++).typeinfo


 Thoughts?


I like it.

-- 
/Jacob Carlborg
Nov 29 2011
parent "RivenTheMage" <riven-mage id.ru> writes:
On 30.11.2011 1:29:16, Jacob Carlborg wrote:


 It would be good if "compiles" could be a block, but that would be
 inconsistent with the rest. Something like this:
 
 meta.compiles
 {
 // code
 }


It can be allowed to pass string as argument (just like in string mixins).
And then:

meta.compiles( q{
//code
})


 This would basically implicitly import meta.d, like object.di?


Yes.


 Would it be possible to extend somehow for a user?


In my proposal - no, it's a part of D runtime.
Nov 29 2011
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 11/29/2011 09:11 PM, RivenTheMage wrote:

 *1) Replace all symbol-related traits with ".metainfo" property*

 __traits(isAbstractClass, A) ==>  A.metainfo.isAbstractClass

 __traits(A.func, isVirtualFunction) ==>
 by name: A.metainfo.members["func"].isVirtualFunction
 by index: A.metainfo.members[N].isVirtualFunction

 __traits(hasMember, A, "func") ==>  A.metainfo.members.find("func")

 Aliasing should be posssible:
 ---
 alias A.metainfo.members mymeta;
 mymeta.find("func");
 ---


 *2) Replace rest of traits with "meta" keyword*

 __traits(compiles, ...) ==>  meta.compiles(...)


 *4) Add special extendable namespace, accesible through "meta" keyword*

 The namespace can be extented by special file "meta.d" which should be a part
 of D runtime. Actually, it's the same thing as std.traits, the intention is
 to put all reflection stuff under one roof.

 instead of:
 ---
 import std.traits;
 int foo();
 ReturnType!(foo) x;
 ---

 it would be:
 ---
 int foo();
 meta.ReturnType!(foo) x;
 ---


 *6) Replace identificator-related "is" expressions with ".metainfo" property*

 is(Identifier ...) ==>  Identifier.metainfo.isXXX(...)


 *7) Replace rest of "is" expressions with "meta.is"*

 is(...) ==>  meta.isXXX(...)


 *5) Replace "typeid" keyword with ".typeinfo" property*

 typeid(int) ==>  int.typeinfo
 typeid(typeof(x)) ==>  typeof(x).typeinfo
 typeid(i++) ==>  (i++).typeinfo


 Thoughts?


Yes, __traits should be replaced by a cleaner design eventually. 
'is'-expressions, typeid and std.traits are perfectly fine as they are 
now and I don't see any reason to make their syntax more complicated.

instead of adding .metainfo we could also just add a bunch of enum 
members to the typeinfo obtained by typeid. (that would bundle static 
reflection and rtti). eg. typeid(A).isAbstractClass
Nov 29 2011
parent reply "RivenTheMage" <riven-mage id.ru> writes:
 Yes, __traits should be replaced by a cleaner design eventually.
 'is'-expressions, typeid and std.traits are perfectly fine as they are
 now and I don't see any reason to make their syntax more complicated.


Before all, why typeid() is named typeID()? The return type is TypeInfo :)
Nov 29 2011
next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 29-11-2011 23:43, RivenTheMage wrote:

 Yes, __traits should be replaced by a cleaner design eventually.
 'is'-expressions, typeid and std.traits are perfectly fine as they are
 now and I don't see any reason to make their syntax more complicated.


 Before all, why typeid() is named typeID()? The return type is TypeInfo :)


Leftover from C++.

- Alex
Nov 29 2011
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 11/29/2011 11:43 PM, RivenTheMage wrote:

 Yes, __traits should be replaced by a cleaner design eventually.
 'is'-expressions, typeid and std.traits are perfectly fine as they are
 now and I don't see any reason to make their syntax more complicated.


 Before all, why typeid() is named typeID()? The return type is TypeInfo :)


It can be used to identify the type because it is a unique reference.

T a,b;
assert(typeid(a) is typeid(b));
Nov 29 2011