-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Felipe Magno de Almeida Sent: Thursday, May 24, 2007 5:27 PM To: boost@lists.boost.org 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