Re: [boost] quince: queries in C++ expressions

Subject: Re: [boost] quince: queries in C++ expressions
From: Michael Shepanski (mps_at_[hidden])
Date: 2014-07-17 20:38:30

On 18/07/2014 2:11 AM, pfultz2 wrote:
>> If you can do *that* with Boost.Fusion then perhaps you can show us the
>> code that does it, and we discuss costs and benefits.
> Sure. You just access the field by using the key.

I know, but that's not what I asked.  I want the syntax to be points->x.

> Here is a quick-and-dirty
> example here(I haven't compiled it yet, but it should communicate the idea):
>
> https://gist.github.com/pfultz2/cfc447c7ccfa8ac2e76f
>
> So then you should be able to write:
>
>      table<person> persons;
>
>      for(const person& p:persons.where(at_key<fields::age>(persons) == 60))
>      {
>          ...
>      }
>
> Another idea is to generate the member in with the key, perhaps something
> like
> this:
>
>      #define QUINCE_GEN_KEY(name, ...) \
>      struct name : __VA_ARGS__ \
>      { \
>          template<class T> \
>          struct lazy \
>          { \
>              T name; \
>          }; \
>      };
>
> Then you can use the fusion keys to compose a class that inherits from each
> lazy member, so you could still support accessing it using the `->`
> operator.
> I don't show an example here.

When you say "you can use the fusion keys to compose a class ...", do 
you mean that the user writes each such class by hand, or can you write 
something that will make it automatic? If you are telling me that 
Boost.Fusion can replace QUINCE_MAP_CLASS etc., then your challenge is 
to make it automatic.

I need to see your code for this, before I can assess whether a 
dependence on Boost.Fusion will buy me a nett reduction in quince code.

>
> However, the first approach I think is sufficient.
>
>> I mean, if I were to take the approach of implementing QUINCE_MAP_CLASS
>> and QUINCE_MAP_CLASS_WITH_BASES by (a) using Boost.Fusion to define some
>> kind of tuple, and then (b) using some other means to turn that tuple
>> into the class I need, then I expect it would all be done in one place,
>> _viz._ inside the definition of quince's private macro
>> QUINCE_DEFINE_CLASS_MAPPER_WITH_BASES.  So I would be introducing a
>> dependency on Boost.Fusion for the sake of changing one point in my code.
> You wouldn't generate your mapper class using the preprocessor, you can just
> generate it using C++ template metaprogramming. Perhaps, you would use the
> preprocessor to generate the keys, but not the mapper or table class(as I
> show in my little example).

Likewise in quince, most of the work of QUINCE_MAP_CLASS etc. is done 
without macros, by something called typed_class_mapper_base (which the 
user never mentions).

It's also perhaps worth pointing out that the whole implementation of 
QUINCE_MAP_CLASS and QUINCE_MAP_CLASS_WITH_BASES is a very small part of 
quince. On the other hand the mapper classes that they generate are 
referenced ubiquitously.

> Boost.Fusion does a great job of handling product types, which an ORM would
> need. It seems unnecessary to reinvent the wheel here.

My philosophy is somewhat different. I don't believe that I should 
accept sacrifices (degraded EDSL, indirect implementation) for the sake 
of using Boost.Fusion. On the contrary, I think any such decision needs 
to be justified by benefits, to outweigh the negative of inter-library 
dependence. Again I cite http://www.boost.org/development/reuse.html .

Cheers,
--- Michael