Robert Ramey wrote:
b) Some posts suggested alterations in libary interface to permit a specific usage of the library. These were of the character as "required to implement bracketing for XML" etc. My view is that it dangerous to alter the library interface to accomodate speculation about future directions. I would much prefer that some take a copy of the library, develop his new "thing" making necessary changes in the libary.
As many persons said, this should be very simple. OTOH, it's fair that you want interested persons to do it, rather that hacking on a feature you'll never use.
The new "thing" then gets judged on its own merits taking
into account the impact that it would have on the library.
I don't think this places any extra burden on the inventor
of the new "thing" and prevents us from making the library
from being harder to use to support features that arn't
added yet.
Frankly speaking, I have one concern. We (you and I) seem to have problems understanding each other. Therefore, if I implement something after the library is accepted, it may be hard to convince you to adopt the change. I may be mistaken, but this is how I feel. Anyway, see below.
5.2 "registration" - A brief recap:
[snip]
Red Herrings
============
a) it has been aledged that the forward declaration method
will preclude archives written by one program being read
by another. I don't know what the basis for this belief was
but in anycase it is demonstrably false. http://aspn.activestate.com/ASPN/Mail/Message/1354725
I believe "demonstrably false" is quite a questionable phrase, both in correctness and politeness. Can you provide any proof? And what's your opinion on http://aspn.activestate.com/ASPN/Mail/Message/boost/1433616 The message talks about two version of the same program, but you can easily adjust the example.
Is it possible to reconcile these differing points of view ?
============================================================
I was not at all prepared for the stridency of the arguments surrounding
this issue. I truely regret using the term "registration" and "register_type". I believe this has contributed to what I see as a huge
amount of misunderstanding as to where type ids fit into this
system. I also confess that I had recognized that someone
might object to the "forward declaration" so I sort of de-enfasized it
in the hope that it might pass "under the radar" with just a little
grumbling. BIG MISTAKE. Oh well.
After much thought, I have come conclude that it is possible
to accomodate the global register idea in a way that
does not complicate the system too much. Basically it would
create a "function" implemented by the preprocessor that looks like
#define SERIALIZATION_GLOBAL_REGISTER(T)\
boost::serialization::instanciate<T>("T");
#define SERIALIZATION_GLOBAL_REGISTER(T, NAME)\
boost::serialization::instanciate<T>("NAME");
That's mostly fine with me. Macro is not 100% needed, you can just use "instanciate" directly. I'd also like to have a second version of "instanciate", which does not take an argument, and uses "type_info::name()" instead. However, I can code that myself in no time.
5.3 "describe"
I was reluctant to embark on a "whole new thing" (reflection) without having first finishing the thing I started out with (serialization). Basically, I didn't feel I could do "describe" right, so that it should be left for later.
That's right. I did not seen any objections to this during review. Did you?
5.4 "XML" XML is going to be a lot more than just writing <classname> .. </classname> tags in the output data. Some issues involved are a) Using a system of C++ reflection to get the names of variables and classes
Or ask the programmer to do it. For some cases, this is perfectly OK.
b) generating XML schema from some sort of DESCRIBE facility as above. This basically inserts the reflection information into the XML archive
And is not needed for me, FWIW.
c) the current library keeps track of data stored by writing class-id and object ids for classes and objects used multiple times. XML containing this type of information might not be useful to other programs that don't contain this serialization system which would defeat the purpose of XML.
1. The data that needs to be processed by other tools might have relatively
simple structure. But at the same time, it may be part of archive which uses
polymorphic pointers, &etc, so it's better not to restrict XML serialization
to some subset.
2. I might imagine the following code
ghost::utils::C* c = ...;
ar << c << c;
producing this XML piece
<!-- declare a class id for "ghost::utils::C" -->
<class cid="2" name="ghost::utils::C" guid="12345678"/>
<!-- store a pointer to C, giving it an id for further
reference -->
<ptr id="14">
<object cid="2">
<x>10</x>
</object>
</ptr>
<!-- store the same pointer to C and use "ref"
attribute to refer to previously saved object -->
<ptr ref="14"/>
Here, there are two complexities
- getting class name/guid by class id ("cid")
- getting previously saved project by "ref".
Both operations are quite doable, if anyone wants it.
I positively wantSuppose I were to make the changes described in sections 1, 2, and 3 above. Would it be approved by boost? If I could be assured that it would be, I would be willing to make those changes. I guess it would take me 90 days. Suppose that the package could not be accepted into boost unless it included "describe" functionality and guarentees implementation of XML. These are two almost completely separate packages which should be separated from serialization. I am not prepared to do the work as I see it as orthogonal to serialization itself. It is my belief doing either one correctly is a is a large undertaking which I am not prepared to commit to. So if this is the position of the majority of boost members, I'm done.
- a better registration mechanism (the one you've described is OK).
- hooks for XML saving
- (maybe) hooks for describe.
If you're about to create the next version in 90 days, then I'm willing to
experiment with XML and other formats that need field names. I'd be happy to cooperate with other iterested persons, if any.
- Volodya
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
