The Wrong Stuff

Jonathan M Davis jmdavisProg at gmx.com
Sun Sep 26 16:25:46 PDT 2010


On Sunday 26 September 2010 12:34:43 lurker wrote:
> I can't even possibly imagine
> why would anyone (except you) want to use their own keywords. It sounds
> like a new treacherous way to invite dangerous macros to the language. The
> reservation of the word macro without giving an implementation is a
> conscious decision to disable all kinds of over-expressive macros in
> forthcoming versions of the language. Providing customized @! keywords for
> 3rd party tools seems like mocking the damn good state of the art
> meta-programming system D has. If I could design D, I'd use @ in front of
> every keyword to avoid namespace collisions with user symbols.

Other languages - like Java - allow user-defined attributes. Certainly in Java, @ 
is not at all intended to be a space for creating new keywords. It's intended to 
be a space for putting attributes of functions and classes and the like. Those 
attributes are sometimes defined by the compiler (@override for instance) and 
sometimes created by 3rd party library or you on your own project.

For instance, there's a 3rd party library (I forget what it is at the moment - 
it's been a while since I used it) which allows you to serialize your classes to 
and from xml using reflection. For that to work correctly, you need to use markup 
on your classes. So, they have attributes along the lines of @xml and 
@xml_transient to indicate things which should or shouldn't be put into xml or 
how it should be translated into xml. It's _extremely_ useful. A number of 
libraries in Java use that sort of thing. There are those among us who'd love to 
have that sort of thing in D.

At present, D's attributes are all fixed, and the choice of what is an attribute 
and what is a keyword is pretty arbitrary such that @ does come across as 
another namespace for keywords, but it doesn't have to be that way. Assuming 
that the grammar is such that @ indicates that the identifier that follows is an 
attribute (as opposed to the whole @identifier being a keyword), then making it 
parse 3rd party attributes would be easy. They wouldn't do anything, but they'd 
be available through reflection (which at the moment, would only be compile-time 
reflection, but perhaps someday we'll get runtime reflection too), and so you 
could use __traits and traits to get at them and your libraries could then 
generate code based on them. It really isn't crazy to want user-defined 
attributes, and it's not necessarily hard (though if you want user-defined 
attributes as good as Java's, you'll need more since they allow attributes with 
parametrs and the like). At some point, Walter may add such a feature. It's 
obviously not high on his priority list right now (which is fine with me), but it 
_is_ a feature which many of us think should be in the language.

- Jonathan M Davis


More information about the Digitalmars-d mailing list