Date: Mon, 25 Nov 2002 11:08:32 +0300
>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.
Well I'm not sure how the process really works but I I would imagine
that it works something like the following.
a) a libray gets accepted to boost.
b) some time after, someone comes up with a next great improvement
c) so he tries to convince the original author to roll in the new
feature but the original author isn't convinced.
d) but the library isn't doesn't belong to Robert Ramey anymore:
it belongs to boost. So you make your new improved version and
submit it to the formal review process (presumably as it would
be an incremental change it wouldn't be as excruciating as
what I've been going through.)
e) the finally things get resolved more or less as they get resolved now.
f) if the boost systems decides to role in the new changes
thats it. If I'm really unhappy - well I still have my pristine copy.
Once I give it to boost, its not really mine anymore. I recognize that this
is how it has to be.
I've pretty much accomplished what I set out to do so my interest
is waning anyhow. I invested much more time in this than I anticipated
and would much like the official acceptance from boost to certify
my accomplishment - though I can live without that if necessary.
Rest assured that if it gets accepted, I'll have no objection to others
making any agreed upon improvements. The boost system make it
most likely that subsequent reviewed changes will be improvements
in any case. Even better, If I can get this in, I'll be please to let
someone else take over as maintainer if someone wants to.
Also I would hope that it is apparent that the library is designed to permit
and encourage extension and improvement. That is the motivation
for trying to keep separate the concepts of serialization, archives,
non-intrusive template serialization, reflection, universal class id, etc.
and for confining my system to just one of those topics.
I concede I have tenatiously defended my design decisions in this
regard - and I don't regret it. I fought to keep from adding features
that don't belong and some people have found this off putting. But
look at the good side. There is whole new territory opened up
C++ reflection which might be combined with serializaton to
make an XML archiver. Universal class ID and plug in system.
These are whole new areas on interest.
>>
>> #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.
The reason that I suggested a macro is that I wanted the class name as the
class ID. This is indeed portable (though not guarenteed to not conflict in another
program
or namespace). I didn't feel I could use type_info.name() because it might
look different when compiled on another system and archives couldn't be shared.
Robert Ramey
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
