[SoC] Boost.Extensios enhancements and Reflection
Hi Boost Community! Maybe you remember that I've sent a couple of emails last days because I want to participate in SoC with Boost. My original idea was a plugin library, and then someone pointed me out the existence of Boost.Extensionsand then contacted its author (Jeremy Pack) to try to enhanced/complete that library. Last days, we've been working together. I reviewed Boost.Extensions, Jeremy reviewed my approach to see if there are any feature that could be added to Boost.Extensions. and then we agreed in a possible list of tasks as a SoC project. Now, we want to share this list with the community, to know if there is something missing or something that anyone in the community would like to see implemented. Our current task list is: - Preprocessor tricks to remove template redundancy - Provide (optionally) automatic closing of unneeded linked libraries. - Implement Reflection. and the required tasks for the completion of Extensions: - Finish up documentation - Write lots more unit tests, as well as larger tests - Submit it to Boost for review We think that the most important parts of the project are submitting the library and doing something with Reflection. Another issue that I must resolve is the mentoring. I know that at least two people offered their help, and It would be great if we can decide that to be able to start to write my proposal, checking it with the mentor and with Jeremy. Thanks! Mariano.
Mariano Consoni wrote:
Hi Boost Community!
Maybe you remember that I've sent a couple of emails last days because I want to participate in SoC with Boost. My original idea was a plugin library, and then someone pointed me out the existence of Boost.Extensionsand then contacted its author (Jeremy Pack) to try to enhanced/complete that library.
Last days, we've been working together. I reviewed Boost.Extensions, Jeremy reviewed my approach to see if there are any feature that could be added to Boost.Extensions. and then we agreed in a possible list of tasks as a SoC project.
Now, we want to share this list with the community, to know if there is something missing or something that anyone in the community would like to see implemented.
Our current task list is:
- Preprocessor tricks to remove template redundancy - Provide (optionally) automatic closing of unneeded linked libraries. - Implement Reflection.
and the required tasks for the completion of Extensions:
- Finish up documentation - Write lots more unit tests, as well as larger tests - Submit it to Boost for review
We think that the most important parts of the project are submitting the library and doing something with Reflection.
This all sounds reasonable. A question though, when you spec of reflection, are you talking about 'full dynamic reflection' -- something like: http://www.vollmann.com/pubs/meta/meta/meta.html because that would be a nice addition to Boost by itself...or is it something more limited?
Another issue that I must resolve is the mentoring. I know that at least two people offered their help, and It would be great if we can decide that to be able to start to write my proposal, checking it with the mentor and with Jeremy.
The deal with mentors is that we can't make final decisions about assignments until projects are accepted and such. But I believe Hartmut offered to help during the proposal phase, so I think you should feel free to email him privately if you want. That said, the more you make public on the list the broader range of feedback you'll get. Now I realize that, in theory another student might pick up your idea and propose it if it's out in the public, but I can't see the mentors choosing someone that behaves that way. And you're already getting bonus points for interacting with the community right from the start :-) Jeff
This all sounds reasonable. A question though, when you spec of reflection, are you talking about 'full dynamic reflection' -- something like:
http://www.vollmann.com/pubs/meta/meta/meta.html
because that would be a nice addition to Boost by itself...or is it something more limited?
I guess that depends on what the community wants, and what Mariano thinks he can handle in the limited time. Full dynamic reflection wouldn't reuse much of the existing code in Boost.Extension. It would certainly be possible to provide a facility for generating and compiling (using Boost.Build probably) linked libraries at runtime, then using the Boost.Extension mechanisms to access it. Or, it could just be fully dynamic classes with fully dynamic methods, as described in the first part of the paper you mentioned. The method that would fit best with Boost.Extension would probably be the ability to instantiate classes that are not derived from known (that is, known to the instantiator) base classes, and then discover functions that can be called on them. Any other thoughts on this?
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jeremy Pack
The method that would fit best with Boost.Extension would probably be the ability to instantiate classes that are not derived from known (that is, known to the instantiator) base classes, and then discover functions that can be called on them.
Isn't this painfully compiler dependent? It would be awesome, totally awesome if one was able to handle it. But that would probably be quite difficult? Maybe __FUNCTION__ can help...
I agree. It would be very compiler dependent to have the library find arbitrary classes in a linked library and determine their methods. What I was thinking of is a bit simpler. It would require a reflected class to have it's reflected methods declared as such. It would be a bit similar to the Boost.Python syntax, except that it would, like Boost.Extension, require only one library entry point and it would need to add some stuff for type safety, without inducing a lot of runtime overhead. On 3/15/07, Sohail Somani <s.somani@fincad.com> wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jeremy Pack
The method that would fit best with Boost.Extension would probably be the ability to instantiate classes that are not derived from known (that is, known to the instantiator) base classes, and then discover functions that can be called on them.
Isn't this painfully compiler dependent? It would be awesome, totally awesome if one was able to handle it. But that would probably be quite difficult? Maybe __FUNCTION__ can help... _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jeremy Pack
I agree. It would be very compiler dependent to have the library find arbitrary classes in a linked library and determine their methods. What I was thinking of is a bit simpler. It would require a reflected class to have it's reflected methods declared as such. It would be a bit similar to the Boost.Python syntax, except that it would, like Boost.Extension, require only one library entry point and it would need to add some stuff for type safety, without inducing a lot of runtime overhead.
I see. Perhaps I should get more familiar with Boost.Python. Would have loved to go to Boost Con. /me shakes fist at new passport requirements Sohail
I guess that depends on what the community wants, and what Mariano thinks he can handle in the limited time. Full dynamic reflection wouldn't reuse much of the existing code in Boost.Extension. It would certainly be possible to provide a facility for generating and compiling (using Boost.Buildprobably) linked libraries at runtime, then using the Boost.Extension mechanisms to access it. Or, it could just be fully dynamic classes with fully dynamic methods, as described in the first part of the paper you mentioned.
I'm very interested in developing things related to reflection, but maybe I don't have the complete information to estimate the times for each possibility. Particularly I think that would be good to reuse the maximum qty of code from Extensions.. and apply that. Could anybody help me with that? I mean, determining the scope of the proposal. I prefer to do something that could be closed in the three months with good quality, instead of doing something with a lot of features but not complete. Thanks! -- Mariano
participants (4)
-
Jeff Garland -
Jeremy Pack -
Mariano Consoni -
Sohail Somani