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