1 files changed, 38 insertions, 0 deletions
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.