<font face="tahoma,sans-serif">David,</font><div><font face="tahoma,sans-serif"><br></font></div><div><font face="tahoma,sans-serif">I believe you are correct, we are talking about introspection; I don't believe anyone has mentioned extending or modifying existing types. Example use cases would be to inspect existing libraries and examine types of interest, such as plugins, or those conforming to specific interfaces to be used in a generic way. At the risk of stating the obvious, a good example would be to drop a library into a plugin folder of a paint application, and be able to enumerate all the types derived from "ImageReader", enabling my fictitious application to load several new image file types with zero configuration. </font></div>
<div><font face="tahoma,sans-serif"><br></font></div><div><font face="tahoma,sans-serif">Clang could benefit from this greatly too, by having an extensions path where you could drop shared libraries, and no longer have to specify -load -plugin, simply specifying switches to enable desired plugins. There are elegant ways to cache metadata extracted from a plugins folder so you don't have to inspect the libraries on every invocation of the application.</font></div>
<div><font face="tahoma,sans-serif"><br></font></div><div><font face="tahoma,sans-serif">Cheers,</font></div><div><font face="tahoma,sans-serif"><br></font></div><div><font class="Apple-style-span" face="tahoma, sans-serif">Stu</font></div>
<div><font face="tahoma,sans-serif"><br clear="all"></font><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse;color:rgb(80, 0, 80)"><strong><span style="color:rgb(153, 204, 255)">Stuart Carnie, CTO</span></strong><br>
<span style="color:rgb(255, 102, 0)"><strong><a href="http://manomio.com/" style="color:rgb(255, 102, 0)" target="_blank">manomio</a> | in retro we trust!</strong></span></span><br>
<br><br><div class="gmail_quote">On Tue, Dec 14, 2010 at 7:52 AM, David Chisnall <span dir="ltr"><<a href="mailto:csdavec@swan.ac.uk">csdavec@swan.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 13 Dec 2010, at 18:37, Stuart Carnie wrote:<br>
<br>
> I imagine some of the things you would need are:<br>
> • A runtime, similar to Objective-C's, which needs some of the following capabilities<br>
> • collection of metadata classes which describe methods, types, etc<br>
> • APIs to read over data sections to extract metadata and generate aforementioned classes<br>
> • Public APIs to query for this metadata, create instances of classes via name, etc<br>
> • Changes to compiler<br>
> • Generation of metadata into special data section<br>
> • Generation of entry points / APIs to compiled libraries, executables to allow you to do things like create instances of classes / types by name, etc<br>
><br>
<br>
</div>It's worth noting that C++ already has some of this via RTTI, although not all of it is public. The classes declared in <typeinfo> give you some information about an object via public interfaces (e.g. what its superclasses are and so on). They also include a name field which contains an encoding of the field types.<br>
<br>
Unlike Objective-C, this encoding is defined by the ABI, rather than by the language, although you can use the typeid operator to get a type info object for a specific type and then use dynamic_cast<> to see which subclass of std::type_info it is. The (BSD-licensed) libelf-tc library in the elftoolchain project has code for parsing these encodings for the old-GNU, new-GNU (Itanium), and ARM ABIs, so it wouldn't be too much effort to create something that gives you more useful introspection metadata.<br>
<br>
This information does not, as far as I am aware, give you type encodings for methods, so that would need to be added, which would modify the ABI somewhat (although not necessarily in an incompatible way).<br>
<br>
One question though: When you say reflection, do you actually mean reflection, or do you just mean introspection? For example, true reflection would allow you to add methods to a C++ class, which would require modifying the vtable. If you're only replacing methods, this is quite simple (although, again, ABI-dependent), but adding methods would be much harder. Creating new types at run time would also be relatively difficult. Simply extending C++ RTTI to provide useful introspection would be a lot easier.<br>
<font color="#888888"><br>
David</font></blockquote></div><br></div>