On 22/07/2014 1:57 AM, Mathias Gaunard wrote:
I don't (yet) see how BOOST_FUSION_ADAPT_STRUCT could be used to replace QUINCE_MAP_CLASS_WITH_BASES.
Also I don't see how any of this is going to produce the mapper classes with all the specific features that the rest of quince needs. I think that would be an extra step.
From what you described, you needed a way to list the members of a structure, like what can be done with tuples. This is what Fusion does.
Yes, I need a way to list the members of a structure. And you assumed that is all I needed -- am I right?
Any type that is Fusion-compatible should be made compatible with your library too.
Quince already allows std::tuples to be mapped types. So I guess quince could, similarly, allow fusion sequences to be mapped types. Then a user who has a class could indeed choose to get it mapped by the circuitous route of adapting it to a Fusion sequence and then mapping that. (It wouldn't be my choice, but to each his own.)
There are plenty of classes all over Boost and elsewhere that are already Fusion compatible. Why not just use this concept instead of reinventing your own?
Obviously I have given numerous answers already. I take this question as a request for a summary. In order to provide the syntax "points->x", I need a macro that generates a class with member names that match the user's member names. None of the admonitions about reinventing wheels etc. have shown how to do that without the macro. The objects I am dealing with are class-like rather than sequence-like, in this sense: they have inheritance (including multiple inheritance). I have asked how Boost.Fusion can do the work of QUINCE_MAP_CLASS_WITH_BASES and there has been no answer. I currently believe that it cannot. Most of the code in my macros is due to the foregoing two points, which are *not* reinventions of anything in Boost.Tuple. So I really think it is time we put the "reinvention" argument to bed. It's a distraction from any other arguments that are still live ... Based on my reading of http://www.boost.org/development/reuse.html , I should only introduce a dependence on another significant Boost library if there are benefits. Now, as just explained, I don't think there are benefits in the form of code savings inside quince, so the quince maintainer is not a beneficiary. Then who is? ... The more recent discussion has mentioned the user who already has classes adapted to Fusion tuples, and who would presumably like to avoid the burden of *also* typing QUINCE_MAP_CLASS or QUINCE_MAP_CLASS_WITH_BASES (aka "having to say their structure is tuple-like a billion times"). Very well, then for that person I concede that there is a benefit it in providing a new sort of quince mapper class, similar to quince::tuple_mapper, but for Fusion sequences instead of std::tuples. Let's call it quince::sequence_mapper. It would be done without macros (just as quince::tuple_mapper is done without macros), it would not support inheritance, and it would not support the "points->x" syntax (which its users probably wouldn't want anyway, since they are using Fusion syntax already). Obviously sequence_mapper would share as much as possible of its implementation with class_mapper (the thing that QUINCE_MAP_CLASS etc. define), and with tuple_mapper, just as those two already share as much as possible of their implementations with each other. As it currently stands, a quince user has the choice to represent an employee as a class or as a std::tuple. If you use a class then you get inheritance and the "points->x" syntax for members. If you use a std::tuple then you get compatibility with any other code you might have that uses std::tuples already. The proposed addition of sequence_mapper would provide compatibility with other code that uses Fusion mappers already. But the reasons for allowing *classes* are still valid imo. --- Michael