On Wed, 18 Dec 2002, William E. Kempf wrote: > > I don't know if there's a > > policy about library submissions depending on closed-source tools. I > > don't think there should be a problem (after all, most compilers Boost > > supports are closed-source), but it seems prudent to ask up-front. > > I'm confused. Above you said it was open-source, now you talk about it > being closed-source?
Sorry for not being very clear. The EDG front-end is closed source: it's used to generate IL, which is then parsed by (I believe) closed-source IL transformation tools (I think EDG considers their IL format a trade secret), to human-readable PDB files. From there, everything is open-source. Since all the binaries are freely redistributable, as is the source (where it is provided), in my estimation the toolkit as a whole meets the Boost license requirements. But I'm not sure if my opinion is the one that counts. ;-) > > Finally, is there anyone interested in working on a reflection > > framework? Does anyone have other ideas on approaching this problem? Any > > comments at all? I'll consolidate the information and put them up on the > > Wiki board. > > I'm very interested in having a reflection library available, but I can't > afford any time to helping with the work, sorry. However, I'd suggest you > take into consideration XTI, which is an idea for reflection in C++ from > Bjarne Stroustrup (there's several links to this on the web, one of which > is http://www.klid.dk/arrangementer/XTI_kbh.pdf, do a Google search for > the others). I think his work on it has stagnated, at least from some > things I've heard from others, which is unfortunate. But I think his work > would be a great place to start from for a Boost reflection framework. I'm definitely looking into this. After educating myself, I was planning on contacting BS about the current status of his project. If anyone happens to know more information, or is in a position to find out more, please do so and/or let me know. TIA. > > Were talking exclusively about reflection now... I don't want this > > muddled with the serialization discussion. They are separate topics. :-) > > But they *can* be related. I know you can do serialization with out > reflection, but I think the serialization capabilities of Java show that > reflection can vastly simplify the implementation of a serialization > library. (Though with out language support you can't access the private > data of an object to make serialization automatic in C++.) I agree. OTOH, I think a full-fledged reflection library will be some ways off. We could start with a bare-bones system designed to explicitly support serialization, but I think it would slow down the adoption of the existing serialization effort, and I'd rather not stir up more controversy (unless there's a clear benefit to doing so, which I don't see). Once a reflection library is more-or-less in place, extending it to handle serialization will be relatively straightforward, whether with a brand-new design or adapting it to an existing library. HTH, --craig _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
