The Thermopylae excerpt of TDPL available online

Don nospam at nospam.com
Mon Nov 2 07:44:26 PST 2009


Don wrote:
> Lars T. Kyllingstad wrote:
>> Don wrote:
>>> Jason House wrote:
>>>> Don Wrote:
>>>>
>>>>> Leandro Lucarella wrote:
>>>>>> Justin Johansson, el 30 de octubre a las 08:42 me escribiste:
>>>>>>>> Actually, I think I like that better than 'traits'.
>>>>>>>>
>>>>>>>> -Lars
>>>>>>> I'm in agreement with whoever suggested 'meta' or just about 
>>>>>>> anything else except  'traits'.
>>>>>>> 'meta', whilst perhaps an overloaded keyword, is still much more 
>>>>>>> user-friendly.  Whenever
>>>>>>> I see 'traits' I get the feeling I need a Ph.D. to understand 
>>>>>>> what it's about.  For some reason,
>>>>>>> I don't know why, 'meta' has an aire of karma about it.
>>>>>> "compiler"? That could open the door to other types of access to 
>>>>>> compiler
>>>>>> internals, AST, etc.
>>>>> Yup. I think the 'magic namespace' approach is a simple, clean way 
>>>>> to incorporate reflection. It could be like Object and TypeInfo, 
>>>>> implicitly available in every module and tightly coupled to the 
>>>>> compiler, but can be viewed by the user as if it were just a 
>>>>> module. It'd be particularly interesting if some of the functions 
>>>>> _were_  actually implemented in library code, when possible.
>>>>
>>>> What about going one step further? You could require an import 
>>>> statement to use traits. For example, import traits=std.traits could 
>>>> reproduce your earlier suggestion, but gives added flexibility to 
>>>> the programmer. It also eliminates a keyword.
>>>
>>> It's too fundamental for that. You can't use template constraints 
>>> without it.
>>> BTW, 'scope' is another possible magic namespace.
>>>
>>> scope.compiles(XXX) -- true if XXX compiles in the current scope.
>>>
>>> More generally, scope.YYY()  would provide metaprogramming 
>>> information about the property YYY of the current scope.
>>
>> Do you mean in addition to or instead of the already proposed 
>> traits/meta/compiler namespace?
> 
> It's another namespace suggestion. Just brainstorming.
> 
>> If it's just about avoiding new keywords I think this feature is 
>> fundamental enough to deserve its own keyword, and all of the above 
>> are more descriptive than 'scope'.
>>
>> Is this "magic namespace" proposal technically difficult to implement 
>> in the compiler?
> 
> See for yourself. For example, the patch below (against svn 234) allows 
> '__traits' as the magic namespace. The existing __traits stuff continues 
> to compile. <g>

And BTW, to allow 'meta' as another synonym for the same magic 
namespace, add this line to lexer.c, line 2960.

     {	"__traits",	TOKtraits	},
+    {	"meta",	        TOKtraits	},
     {	"__overloadset", TOKoverloadset	},

(Hmm. Didn't know __overloadset was a keyword. The things you find...)



More information about the Digitalmars-d mailing list