Re: [Boost-users] boost.extensions and boost.reflection.

Subject: Re: [Boost-users] boost.extensions and boost.reflection.
From: Jeremy Pack (rostovpack_at_[hidden])
Date: 2008-09-15 15:29:36

German,
On Sat, Sep 13, 2008 at 1:13 AM, Germán Diago <germandiago_at_[hidden]> wrote:

> Sorry for my mistakes in the code. I wrote very quickly. Anyway, I
> think the basic idea
> is understood. Please do take a look at the papers, I think the use
> cases can be
> understood.

I won't have time to dig into the second and third papers today (though I
have read the second one recently, and you'll notice that I use the same
types of techniques in the parameter_map class), but I do have a couple of
questions:

   1. Could you send me the corrected version of your code? If I match the
   API for the "mistakes in the code", you won't get what you want :) It's not
   entirely clear which parts are mistakes and which are on purpose.
   2. What API would you prefer for exporting such classes?
   3. What are YOUR specific use cases? I know what the use cases of the
   authors are - but if it is those use cases that you need, you ought to use
   the code that they have written instead. Much of it is, I believe, open
   source.

What you propose seems to be a special case of the Adapter Pattern. In that
case, perhaps it could be implemented something like the code I put into:

http://svn.boost.org/trac/boost/browser/sandbox/libs/extension/examples/value/

I threw this code together in less than ten minutes, meaning it doesn't
support multi-parameter constructors and a few related things. The basic
idea should be there though. Is this the type of thing you are looking for?

The declaration of the various boilerplate classes could certainly be
shortened by using macros, but I'm not sure it's worth putting in as actual
library functionality since many users might need highly specialized
versions of the adapters (and because macros are ugly, and I need a really
good reason to use them).

Jeremy Pack