The Thermopylae excerpt of TDPL available online

Don nospam at nospam.com
Mon Nov 2 02:14:28 PST 2009


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.




More information about the Digitalmars-d mailing list