Meta information parser

[pragma]

In article <e5q51e$1te3$1 at digitaldaemon.com>, Sjoerd van Leent says...
>
>I would be in agreement with all this. Yet I also consider that we 
>shouldn't make code bloat when it isn't asked for. For an example, a 
>device driver developer might not want to have access to runtime 
>information and code emission, only perhaps for a small part of the 
>software. The same goes for the GC. However, a business application 
>developer does want to have such features.
>
>The suggestion of using the pragma statement seems good enough. You 
>could just write:
>
> [snip]

Actually, with the pragma() statement, I was thinking more along the lines of
using D's syntax more directly.  Pragma statements are defined as taking the
following forms:

pragma(foo);
pragma(foo): /* statements */
pragma(foo){ /* statements */ }

The second two forms are of particular interest for reflection support:

pragma(reflect): class Foo{ /*...*/ }
pragma(reflect){
class Bar{
}
}

Incedentally, as Walter has outlined the use of unsupported pragmas, this opens
the door for specialized compiler/preprocessor support, as the 'reflect' pragma
is currently just an idea or reccomendation.  So again, there's not a whole lot
keeping someone from drafting a reference implementation now. ;)

>Same goes for CORBA, though be it a bit more complex. One could even 
>emulate Java RMI, or eventually make a D Interface Registry, perhaps 
>looking like a combination of COM, RMI and .NET GAC.

I like how you think, and I completely agree with you.  If you don't mind,
here's my $0.02 on all this:

I really think that the killer feature to make all of the above work seamlessly
is runtime proxy /generation/. For example, the following would work nicely:

IFoobar foo = RMIConduit.getObjectProxy!(IFoobar)(someUUID);

.. if the call to getObject() can return an object instance that supports
IFoobar, that is a proxy for a remote object.  Said object instance would have
all of its vtable entries point to methods that use the associated conduit.
This way, the RMI portion of things is totally seamless beyond the getObject()
call.  Of course, this would depend on some yet-to-be-determined reflection
mechanism (not to mention some form of runtime code-gen).  As this example uses
defined interfaces, it could even be a compile-time template setup of sorts.

And of course, to make the above work with types that participate in class
hierarchies and more, a compile-time reflection setup just won't cut it:

Foobar foo = cast(Foobar)getObjectProxy.getObject(someUUID);

Object registration would probably work in reverse, having the RMI API digest
the object's particulars by reflection.  Thankfully, this step doesn't involve
any codegen and is very straightforward:

UUID id = RMIServer.registerObject(foo);

I guess what I'm getting at is there's more to the picture than just reflection:
having it cooperate with a code-generation API is an important consideration
too.

- EricAnderton at yahoo