Compiler patch for runtime reflection

Jacob Carlborg doob at me.com
Thu Oct 27 00:14:35 PDT 2011


On 2011-10-26 21:53, Adam Wilson wrote:
> It's also interesting that you bring up WPF because the project I lead,
> The Horizon Project, is an attempt to create a open-source
> multi-platform framework that is as easy to use as the .NET Framework
> and one of it's core pillars is a declarative XML based UI design
> language. I am evaluating D and so far it is blowing C++ out of the
> water, (we'll need to have long conversations about strings though, I
> think .NET has the right answer here) but I have to admit that I am
> seriously missing Reflection. The problem is that there is currently no
> way to do data-binding without member-level reflection because it is a
> purely run-time concept. That said, I am researching ways around this,
> and I do have ideas ... but that's not for this forum.

Are you saying that you consider using D for this Horizon project? I can 
recommend you take a look at DWT: www.dsource.org/projects/dwt

Somewhere down the road I've planed to create an interface/window 
builder for DWT using XML or something similar. I'm thinking something 
like how it works on Mac OS X using Interface Builder.

> However, I see no particular reason to reflect on private members by
> default, if you need to get data out, you should be using a public
> property or method to filter the data as needed, that's kind of the
> point of scoping. Private member reflection is NOT a requirement for UX,
> WPF being the case in point. I personally like the solution that
> Reflection in D is opt-out with both command-line options and
> @noreflect. I would add that a @deepreflect option be made available for
> those incorrigible souls who absolutely must reflect private members. I
> would also add that reflection should be default disabled by the
> compiler for code the works directly with pointers and direct memory
> access (malloc/free, new/delete, etc.) and the developer can only enable
> it using a compiler option.

I don't understand this one. Should the compiler disable reflection as 
soon as it sees malloc/free? On what level should it be disabled? I 
mean, the runtime needs to be able to use these functions to implement 
the memory manager, i.e. the garbage collector and other things as well.

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list