From 1927f6d00ca32101de2554946e8b449efb5977c1 Mon Sep 17 00:00:00 2001 From: Boris Kolpackov Date: Thu, 9 Oct 2014 11:29:38 +0200 Subject: Start tracking ODB change development in git --- feature/composite/interface-type | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 feature/composite/interface-type (limited to 'feature/composite/interface-type') diff --git a/feature/composite/interface-type b/feature/composite/interface-type new file mode 100644 index 0000000..a5f61ab --- /dev/null +++ b/feature/composite/interface-type @@ -0,0 +1,38 @@ +Some existing value types (e.g., time_period in Boost.DateTime) do not +provide modifiers and the only way to initialize such types is by passing +everything at once in a constructor. For such types it would be nice to +be able to use another, "interface" type to capture the data and then +use it to initialize the desired type at once. The same logic would +apply to persisting the type in the database. + +In fact, we already can do this via virtual data members just very +awkwardly -- one has to specify the interface type (as virtual member +type) as well as to/from conversion functions (as accessors and modifiers) +for every data member of the target value type. So it seems pretty +straightforward to allow specifying this once for a type. + +We already have a very similar mechanism: extended database type support. +The only difference, really, is that there it is about database types and +here it is about C++ types. + +Tricky stuff: + + * There can still be accessor/modifier expressions at the element + level (will have to compose the calls). + + * Containers could be tricky: for them we require by-reference + access. Yes, containers might not even be supported since we + do simple value and container init in separate functions so + a stack-based temporary won't work. This will probably be ok, + however, since the use-case is to facilittate mapping of existing + composite value types and it is unlikely they will use containers + (or maybe not). + +This will need to be implemented as "for all intents and purposes use this +other type as the composite value type except in two places: when getting +const& from the object and when setting value (std::move()?) to the object." + +Could this be something that's also useful for simple value types? Yes! Real +use case: custom lazy ptr (implements loading in ->). Being able to use +standard lazy ptr as interface type would be useful. Right now have to go +through virtual data members. Not going to work well for templates though. -- cgit v1.1