Proposal: user defined attributes

Steven Schveighoffer schveiguy at yahoo.com
Tue Mar 20 09:09:35 PDT 2012


On Tue, 20 Mar 2012 11:17:02 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Perhaps we should add a field of type Variant[string].

1. Variant is not (and shouldn't be IMO) part of druntime.
2. This is *static* data that should be available at compile time.  D's  
runtime wasting cycles filling in static data (including lots of heap  
allocations) seems like a big enough detriment that compiler help is  
warranted.

>> This is an already ridiculously hackish approach, and
>> it *does not* work for anything besides trivial applications. It is
>> completly unreasonable to expect everything to be done in a library; the
>> compiler exists for a reason and at some point you have to draw the
>> line.
>
> I'm afraid I disagree. A targeted language feature definitely makes a  
> library approach inferior, by definition. But adding features is  
> cheating, like printing money is for a government: very tempting, with  
> apparently good short-term benefits, but with devastating cumulative  
> effects.

Not exactly.  We could all be writing code in assembly if "adding  
features" was always caustic.

What is nice about adding this feature is it provides a custom solution to  
hooking the compiler's TypeInfo generation.  We are setting up the  
compiler to give us hooks so we *don't* have to extend the compiler every  
time we want new reflection features.

One of the oft-requested features of D is reflection capability.  The  
answer is generally that we have compile-time reflection, which can  
theoretically be used to build runtime reflection.  However, the rebuttal  
I always come back with is "yeah, but why should I build at runtime that  
which is obvious at compile time?"

Note that one library that did attempt runtime reflection capability  
(flectioned) does all this at runtime, and does some really funky shit,  
like opening /proc/self/map on Linux, or requiring you to pass an OPTLINK  
map file.  I don't look at these as "innovations" as much as I do as  
workarounds.

> Also, as I mentioned, the availability of the easy escape hatch of  
> adding a language feature thwarts creativity. Nobody will care to think  
> about and come with idioms that use the language to do great things, if  
> they know a language feature could be always added that makes things  
> "nicer".

I have to disagree for this instance, the barrier to creating reflection  
data from compile-time info is very large.  If anything, this *expands*  
the ability to create, since you now have a new way to pass information  
 from compiler to runtime.

-Steve


More information about the Digitalmars-d mailing list