Re: [boost] [extensions] some implementation questions

From: Jeremy Pack (rostovpack_at_[hidden])
Date: 2007-05-28 21:18:11

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Felipe
> Magno de Almeida
> Sent: Thursday, May 24, 2007 5:27 PM
> To: boost_at_[hidden]
> Subject: [boost] [extensions] some implementation questions

> 1. What is BOOST_EXTENSIONS_IMPL_NAMESPACE_BEGIN used for?
> It doesnt seem to add anything useful. Just complicates the
> implementation.

The file where you saw that is an old test file from another programmer who
was offering a suggested implementation. It is not currently used in the
library. I haven't cleaned it out of SVN yet, but I will - I wanted to make
sure that I'd implemented his most important ideas first. I left that file
there as a reminder. You can safely ignore the impl folder for now.

>
> 2. Why is functor defined? Why not use boost::bind and
> boost::function ?

functor was defined in order to make this library work with or without the
Boost libraries. The current plan is to replace it with boost::function
though, as you suggest. This is part of Mariano's proposed work for SoC. I
would like to check what other dependencies that would pull in from Boost.
Many people do not have approval to use the full Boost libraries in their
project - the less of Boost pulled in, the more likely they could get its
usage approved.

>
> 3. Why does shared_library have two-phase construction?
> It seems to be common knowledge that two-phase construction is bad.
> IMO, a default-constructor and a constructor that throws
> would be better. And member functions for both options too.

The design of the shared library class is a bit of a contentious issue. We
will iterate on the design a bit, and then see what the Boost community has
to say about it in general. You may also notice that there aren't many
declared exceptions yet. All of this will be looked at and worked on.

>
> Now, IMO, factories are unnecessarily complicating the library.
> Couldn't a different approach be pursued? Like serialization
> does for type registration.

Some of the planned reflection functionality will work best using factories.
Also, I fail to see how the serialization type registration would make this
any less complicated... The factories simply call the constructor (though
they could certainly do more than that). Could you give me an example of the
API you'd rather see?

<http://lists.boost.org/mailman/listinfo.cgi/boost>Also, the serialization
type registration will, time permitting, be usable with this library. We've
discussed using extended_type_info in place of standard RTTI, and I've built
in a facility where the programmer can provide his own version of type info
(for instance, you could give each constructor type a unique integer ID).

Jeremy