On Tue, 20 Mar 2012 12:16:41 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 3/20/12 11:09 AM, Steven Schveighoffer wrote:
On Tue, 20 Mar 2012 11:17:02 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
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.
This is trivializing my point. Please.
Well, then let's not compare the hyperinflation of the economy to adding a
compiler feature. There are certainly good reasons to add compiler
features, without devastating cumulative effects.
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.
There is something nice about every new feature.
Yes, but this nicety is not just syntax sugar or a shortcut, it's adding a
whole new opportunity of communication through the compile-time/runtime
barrier.
I think Adam Ruppe's post on how he tried to use library code to
accomplish this is quite telling. The comparison to OO programming in C
vs. C++/D seems quite appropriate. And I've written Xt widgets, so I can
vouch for how shitty it is to do OO programming in C.
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?"
I thought there were discussions that didn't add runtime overhead.
I haven't seen that. Perhaps a link?
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.
Maybe there's a better approach than flectioned. Consider the language
is frozen solid. How would you solve problems with it?
I think the closest anyone has come is Jacob, with his orange library.
Maybe he can respond to this point.
-Steve
