From: David Abrahams (dave_at_[hidden])
Date: 2007-08-08 13:02:39
on Wed Aug 08 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
> David Abrahams wrote:
>> on Wed Aug 08 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
>
>> Then, as with the Python library, we have the opposite problem: most
>> other libraries are dependent upon Serialization.
>
> Hmm "we"?
Umm, yes. Like it or not, we're all in this together. Dependencies
can cause problems for the maintainers at both ends of the relation.
> I would say that if that is a problem, it would be the problem of
> the library maintainer and he can/will decide how much he wants to
> depend on another library. I don't see the serialization library
> any different than any other library in this regard.
It's very different, because it's not an implementation detail. If I
write a library of containers, nobody will come to me complaining that
"your library doesn't support type_traits." They are likely to
complain that I don't support Boost.Serialization (or Boost.Python).
> Of course if the library maintainer wants to make serialization of
> his types an optional part or of his library he's free to do so
> using a command line arguement to bjam or whatever. But still - its
> up to him -
Of course it's up to him. Who implied otherwise?
> its not a boost problem.
When it becomes an issue that many library authors have to deal with,
it becomes a Boost problem. If everybody deals with it in a unique
way, we will have more problems than if we have a coherent pattern to
follow that minimizes release and testing problems.
>> In reality, python bindings and serialization code are separable
>> and optional parts, and we ought to have some way to treat them as
>> such from the point of view of the testing and release processes.
>
> Most of the other libraries which contain serialization code
> have a separate (and optional) header for it (similar to
> the headers in the serialization library for stl collections) so
> I don't think there is a lot to be concerned about here.
If serialization and python become "prerequisite libraries" just
because other libraries "depend" on them, that's a big problem. These
problems are not insurmountable, but they deserves attention.
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com