Thoughts on C++20 constraints and concepts

[Thomas Ivesdal-Tronstad]

Hi,

I've been interested in DCI for a while, but so far most languages have, in my opinion, been lacking in features required to make it a feasible approach in many cases.

Now with the C++20 core language feature constraints and concepts things have changed. I have written a simplified money transfer example that is using that feature. Still I don't think this is enough since the only legal bindings between objects and roles are those known at compile time, and if I've understood DCI correctly one should be able to create new object types at runtime and bind those to roles of previously defined context types.

I have uploaded my example to github. Any thoughts?

https://github.com/thives/dci-example-cpp

[James Coplien]

On 22 Jul 2019, at 22.31, Thomas Ivesdal-Tronstad <tho...@lyse.net> wrote:

Hi,

I've been interested in DCI for a while, but so far most languages have, in my opinion, been lacking in features required to make it a feasible approach in many cases.

Now with the C++20 core language feature constraints and concepts things have changed. I have written a simplified money transfer example that is using that feature. Still I don't think this is enough since the only legal bindings between objects and roles are those known at compile time, and if I've understood DCI correctly one should be able to create new object types at runtime and bind those to roles of previously defined context types. 

I call both of them DCI. One of the earliest (maybe the earliest, I don’t remember exactly) implementations worked statically. As with other dichotomies between C++ and Smalltalk, the C++ implementation makes it impossible to get a “message not understood” problem at run time, as is likely to happen when assigning an object to play a role without having the right instance methods to respond to the Role’s role-player contract. It comes at the expense of some flexibility, but after all these years, I have still to identify a real case where one might need it.

I have uploaded my example to github. Any thoughts?

I get it. And the semantics are right. Actually, that’s saying a lot. I’m not a big fan of concepts, though, so it tweaks my mind in a slightly uncomfortable way.

I do think it’s worth publishing somewhere.

https://github.com/thives/dci-example-cpp

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/object-composition/d993631f-ad34-4036-bcff-640733ee98d2%40googlegroups.com.

[Thomas Ivesdal-Tronstad]

Thank you for your response. It is reassuring that you consider both DCI.

I do have one thing that I am concerned with - object ownership, or lifespan. Yesterday I started working on a context that is a RabbitMQ pubsub client. This context will be creating arbitrary objects depending on the exchange and routing key of the received message. I guess that's wrong, the messages are themselves objects and my context is simply transforming the same object from a text representation to a binary representation. Now I don't think it makes much sense that this pubsub client should own or control the lifespan of these objects, so what would be the correct approach? Perhaps having a managing role in the client context that takes care of this? Perhaps the object(s) to be managed could then be considered parameter(s) in a role method of the managing roleplayers system operation.

Another problem I'm facing is regarding threading. Simply put if I want to use my pubsub client in a graphical application then waiting for messages with the main thread is bad. If the view is considered an object and my pubsub client is considered an object, then necessarily they will have to operate with several threads. Now according to http://fulloo.info/Documents/DCIExecutionModel-2.1.pdf DCI only supports single thread execution. I am worried if I end up having to make absolutely everything thread safe.

Am I on the right track, or veering off?