Disallow shadowing

Our primary locus of design attention in DCI is the topology of Interactions between Roles in a Context. The interactions happen through role methods sending messages to other Roles and we therefore have a natural primary focus on role methods.

If a role-playing object happens to have an instance method with the same name as a role method of the role it plays we say that the role method "shadows" the instance method and we have an unwanted ambiguous situation of which of the two methods will receive a message.

If the role method has a unique name different from all instance methods, there's no shadowing and it will naturally be called if we send a message to it with its name.

Our primary concern in both cases is to be able to rely on our role method being called since the interactions via role methods in the DCI Context has our primary design focus and we don't want to find a shadowed instance method suddenly being called! ScalaDCI therefore tries to prevent shadowing where it can by throwing a compile-time error. And if shadowing goes un-detected, ScalaDCI guarantees (1) that:

A role method will always take precedence over same-named instance methods.

At compile-time we can most often detect "intentional shadowing" when a programmer both asks in a role contract for a certain instance method and at the same time defines a role method with the same name. In such cases we throw a compile-time error and ask the programmer to either re-name the role method or change the role contract.

If we can't infer the type of the instance class (and thereby its potentially shadowed methods) at compile-time, we ask the programmer to help with a type hint to allow the macro to detect potential shadowing.

At runtime it is impossible to always predict shadowing and we consequently let the role method take precedence in case it shadows an instance method.

So we can therefore safely (1) presume that if we define a role method, and send a message to it on a role-playing object, it will always be that role method receiving the message. No matter if there's a shadowed instance method or not, and no matter if we consider the compile-time or runtime environment. A role method simply always take precedence. And we can safely maintain our primary focus on the Interactions of our DCI Context.

(1) Disclaimer: without going to the MOP etc...

'sef' and 'this' resolving to role-player

v0.5.4

'self' and 'this' now resolves to role-player!

camelCase role names and reintroduction of `this`

v0.5.3

Reintroducing `this` as role-player reference

Upgrading to Scala 2.11.6

• Keeping up-to-date with Scala 2.11.6
• Splitting out coretest from core

Analysis/transformation separated + core specifications added

• Analysis and transformation of the AST has been separated into separate files to make it easier to find where error messages (mainly in the Analysis part) and transformations happen.
• Core test of syntax and semantics of DCI have been added.
• this as a role player identifier has been deprecated since it goes against standard Scala semantics of pointing to the Context instance in our case.

First version on Sonatype!

v0.4.1

Release  0.4.1

Scala DCI with role keyword

role keyword added for intuitive role definitions