COH = Code object hierarchy.

It would be very cool if we had access to the complete code set in, say, an associative array:

COH["mymodule"]["myclass"]["myinnerclass"]["foo"][0].ReturnType

would be the return type for the first mymodule.myclass.myinnerclass.foo

COH["mymodule"]["myclass"]["myinnerclass"]["foo"][0].Attributes[0]

would be the first attribute of the first function foo(for multiple overloads)

COH["mymodule"]["myclass"].methods

would return the methods of myclass

COH["mymodule"]["myclass"].methods.find("foo")

COH["mymodule"]["myclass"]["myinnerclass"]["foo"][0].Signature
COH["mymodule"]["myclass"]["myinnerclass"]["foo"][0].CodeBlock
COH["mymodule"]["myclass"]["myinnerclass"]["foo"][0].Contract
COH["mymodule"]["myclass"]["myinnerclass"]["foo"][0].Signature
COH["mymodule"]["myclass"]["myinnerclass"]["foo"][0].Attrubutes
etc...

The point being, regardless of how it is done it would be handy to have a structured way of accessing code at compile time. The compiler would fill in all the data in a lazy way(but attempt to fill in as much as possible before running ctfe's).

It would be analogous to DOM in javascript but allow things like replacing a code block:

COH["mymodule"]["myclass"]["myinnerclass"]["foo"][0].CodeBlock.replace("return;");

This might be easy to do already using opDispatch and opIndex to wrap a bunch of traits calls?

On Tuesday, 25 February 2014 at 21:05:08 UTC, Jason Macaronie wrote:
> COH = Code object hierarchy.
>
> It would be very cool if we had access to the complete code set in, say, an associative array:
>
> COH["mymodule"]["myclass"]["myinnerclass"]["foo"][0].ReturnType

This isn't my area of experience, but I believe the design of compilers would mean that much of this information will be missing (for example you can't have all the details about a class while you're building the class)

Your general desire, I believe, is summed up in these two things:

http://forum.dlang.org/post/aiipgaqyddjijpjiulfu@forum.dlang.org

http://wiki.dlang.org/DIP50