Thread: CAMP - new open-source reflection library for C++

Again. If you know this, why not be clear about what your work is and is not capable of?

I try to. I've given examples, comparisons with existing frameworks, technical and design details, etc. but it's hard to explain clearly because it's an API which is designed to abstract things. And the abstraction itself is meaningless without modules, and there is no module right now (I'll talk more about this below). So you have to use your imagination, or simply give your opinion about the examples that I've already given, which are clear enough I think.

The protocol you've developed is not practical because the additional burden on the developer. You need to alleviate this burden if you want this to be widely acknowledged. As much as I hate implementation macros, I feel this protocol could be improved with additional macro facilities to reduce repetition and the initial burden.

Macros would add even more verbosity because the lack of templates and overloading. If you look at boost.mirror, which is entirely based on macros, it's kind of ugly actually.
The only thing that would ease the work of the developer is a precompiler, which is not incompatible with CAMP like I said before.

I'm not even sure how this library alleviates the issue. As far as I can tell, it only supports a few trivial primitives ("dumb string"). You'd still need to code the necessary compatibility layer the API for the embedded language interpreter expects. I suppose, in the fullness of time, new primitives for popular projects may be available.

Indeed. CAMP now needs to be enriched with common modules (see below).

I imagine that also applies to other facilities that "vanish" like operators, function overloads, and variable argument functions?

It depends. It's currently not supported but it could be. It would be limited to script languages, but it could be useful.

About the modules

This is the main problem in my opinion. Right now we only provide the core API so that developers can declare metadata, but there's nothing that you can do with it without some extra work.
But now that the core library is stable enough, and that the website and the forum are ready, we'll focus on writing such modules:
- a CAMP-specific precompiler
- a GUI object editor
- a Python module
- a Lua module
- a XML module
- anything that people might find useful
- ... plus all other modules written and shared by the community
The philosophy of CAMP could be "bind once, use everywhere".

So you'll soon be able to get all these features for free if you use CAMP. And with the precompiler it is even more free.

I've given examples, comparisons with existing frameworks, technical and design details, etc. but it's hard to explain clearly because it's an API which is designed to abstract things.

o_O

Then you need to tell people that it is a library designed to simplify and improve the adaptation and binding of C++ constructs for "third-party" API consumption originally targeted at those dealing with embedded language interpreters.

Macros would add even more verbosity because the lack of templates and overloading.

O_o

You should look over my post again... carefully. I never said to drop templates or overloading. You are obviously using both to "guess" the return type and parameters. Dropping either would be foolish. I suggested a layer that would add to the existing API.

CAMP now needs to be enriched with common modules (see below).

Until you have some modules, I suggest you stop using the examples you have used. You come off as claiming features it does not possess.

I also suggest you start with XML.

The philosophy of CAMP could be "bind once, use everywhere".

That's a fine goal, but you first need the one automatic binding.

Soma

Then you need to tell people that it is a library designed to simplify and improve the adaptation and binding of C++ constructs for "third-party" API consumption originally targeted at those dealing with embedded language interpreters.

Thanks for the definition. We're not native english, and finding the right words is sometimes difficult.

You should look over my post again... carefully. I never said to drop templates or overloading. You are obviously using both to "guess" the return type and parameters. Dropping either would be foolish. I suggested a layer that would add to the existing API.

Sorry for misunderstanding.
But how would they make the current API simpler? Please give examples of what you have in mind.

Until you have some modules, I suggest you stop using the examples you have used. You come off as claiming features it does not possess.

But people need these examples to understand what they'll be able to do with CAMP. I'm not claiming that these features are implemented and available, just telling people that they are typical examples of things that can use CAMP.

I also suggest you start with XML.

Seems to be simpler than writing a script module, so it might be the first one, yes.

That's a fine goal, but you first need the one automatic binding.

Definitely.

I would say those modules implement features that can be dealt with without reflection.

How could they? They are not supposed to know what user classes and properties will have to be available.
You must admit that those Qt modules are rather powerful, and they are because they use the Qt meta-object system. If not, please explain your point of view more in depth.

It complicates matters to its user as we both agree. I'd prefer to write two or more script language bindings, than to use this. The work load must be on the library writer. Not on the user of the library. Why would I want to use a library that puts all the work on me? Or, to put it in another way, why should I write a library that puts all the work on the my users?

I don't understand why you think that writing multiple bindings is less work for the user than writing a single one.
Let's say that you want to support both Lua and Python in your application. Using boost.python and luabind, you're going to write twice the binding of each class, and they will nearly be identical (because luabind is inspired from boost.python).
How is that simpler than writing a single CAMP binding (which will also be identical because CAMP is inspired from luabind)?
Please explain what you mean, don't just say "it is simpler ... it is more work ...". Tell me what would be simpler and less work.

This is an interesting point of view, to which I agree, but how is that related to CAMP? We're not talking about what to bind, but how to bind it, whether it is interfaces or concrete classes.

Basically, what I'm interested in is to know if you consider the well known boost.python and luabind as useless as CAMP.

I'm illustrating that binding to Lua is not a benefit of your system. Many other APIs allow this. The fact that yours can bind to internal data in Lua is of no benefit to me since I don't do that anyways b/c I feel it is a bad design. Therefore.....your CAMP offers nothing for me.

I've been working on a project where I've developed a C++ plugin api for adding user interface components and so on to an interface builder application. I think this project could be very useful for me... I already have a mechanism for exposing variables and attaching actions to components, but one piece that I've been missing has been a way for plugin components to expose signals and/or slots and to let users make connections at run-time. Since this has to be done at runtime, a template based approach to signals/slots won't work. I like what the creators of Qt have done, but I don't think it would be easy to rip out their moc preprocessor and to retool it for my own purposes... So, I'm going to take a look at what you've done and try to get my head around it...