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