interaction methods such as withdraw and deposit not resolving in IDE

[ShahOdin]

I haven't looked at the implementation of context, etc. but could you elaborate on the reason you have decided not to use implicits? in the implicit lingo, the interactions would be dataOps. (see here)

And if you'd be happy to use implicits, could you specify the benefits that the context framework brings to the table?

[marcgrue]

We had long discussions and test about using implicits that were finally rejected since, as I vaguely recall it doesn't meet the DCI requirements of for instance having a single object identity. An implicit conversion creates a new object with another identity so Role binding with implicits violates a fundamental requirements of DCI.

With the scala macro no new object is created and object identity is therefore maintained. The data object simply calls a "role method" that the macro prepares. The example of the transformed code in the readme shows how it looks...

Here is one of the old discussions: https://groups.google.com/d/msg/scala-user/nk4V-infctI/JtIpnplRBG0J

[ShahOdin]

I see. It would have been nice if such requirements were expressed as property tests to give the users a clearer picture of what the framework tries to do and what it doesn't. People use property based testing primarily for automatic testing of edge cases, I find it helpful however also for giving an overview of the functionality in a system.

I guess I should read up on DCI a bit more. I had a little experimentation with the concept of roles from a somewhat different perspective in C++ which didn't really get beyond the stage of a prototype ( because well, C++...) but you can see it here. In there I have summarised a number of properties of the system in my app. Perhaps you could find them useful. Also, I would appreciate to have your feedback on the approach: its strengths and weaknesses and whether there is potential for re-implementing it in a more powerful language like Scala.

[marcgrue]

I think it's a good idea if you have a chance to read up a bit more on DCI since this will give you an understanding of why and when to use DCI. I personally find DCI a good fit to implement Use Cases with Actors (=Roles) interacting with each other. If there's only one operation/script/algorithm I generally don't see the need to use DCI. I can highly recommend reading "Lean Architecture" by James Coplien as a start!

I would also suggest to study the DCI tests if you haven't already. In the Shopping Cart examples you'll also find a lot of the reasoning explained behind various implementation variations.