[EMAIL PROTECTED] said: > On Wed, 18 Dec 2002, William E. Kempf wrote: >> 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.
Well, just to voice my own annoying opinion... ;) I am personally *MUCH* more interested in reflection. I can usually deal with hard coded serialization with out the advanced factory creators and/or pointer handling infrastructure. However, I can find uses for reflection on a daily basis. I realize this is only because of the types of software I deal with, and that others will have different experiences, but because of my own experience I'd much rather see reflection. So my personal priority would be to have a _FULL_ reflection framework before addressing serialization. That said, since I don't have time to work on this, I'll have to live with the priorities that those who do volunteer to work on it want to put in place. I just hope that if the priorities aren't set in stone yet, that I can sway some opinions ;). William E. Kempf _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
