Re: Back to basics in Scala

[James Coplien]

More seriously, I think there lies some ambiguity here about what Context means and, by inference, what a Role means.

To me a Role is always defined in terms of its relationships to other roles. I can't think of a counterexample in vernacular language. The dictionary gives the vulgar definition related to a theatric performance but even there talks about part in a play. The foundational definition is a function assumed or part played in a particular situation. In both cases the definition of Role cannot be separated from the Context. By the same token, a Context is defined largely by its roles and interactions.

This is clear enough to me that I've included it in an example in the fulloo.info FAQ. That my brother Gregg and I are brothers makes sense only in the context of a family. That I am a father and Trygve is a son says nothing about our relationship in any Context except that of the family that defines the relationship between the objects that play those roles. This is a definition of role that relates to sociolinguistics and not at all to programming languages. However, it is a much stronger consideration than any PL consideration and I think governs how we must express it in those languages.

I agree with Rune about the aliasing. What makes a Waiter taking an order, a different role than a Waiter delivering food? The interactions with other roles. It may also be that the role exercises different role methods in these two cases but that doesn't mean it's the same role.

There is another interpretation of the word role with is "collection of related behaviors that consistently show up on objects with similar characteristics." We sloppily call that a role, and quickly jump from the notion of Java interfaces to this notion of role. Java interfaces can be used to express the characteristic behaviors of role (but it doesn't go far enough to express role in the DCI sense, because there is no associated method text) but can also be used to express something else that I claim it is not a role. I would like to call this notion a partial class. Like a role it is pure behavior. However, it is not defined in terms of any interaction with any other role: only in terms of some characteristics of an individual object in isolation at a given time. That is just class-oriented thinking translated to run time: sitting inside the object looking out instead of considering how roles partition the overall behavior of the system operation, in the context (ahem) of that system operation.

Let me propose that if I define the Role DestinationAccount as something having the ability to increase balance and report its balance, I'm talking only about a partial class and not a role. If I talk about its relationship to a SourceAccount and an Amount in the broader Context called MoneyTransfer, then it's a role. A role is a collection of behaviors, but it's much more than that. Linguistics tell us so, and that seems to fit the DCI notion of a role in a Context.

On Jan 22, 2012, at 12:26 , rune funch wrote:

Human languages are ambiguous and just because something is _called_ then same in two different context (English) does not imply that they are the same. Eg. An account might be a representation of my balance and previous interactions with the bank. It might also be a representation of a customer in a sales context (think key ACCOUNT manager). They both might be in a transfer context. In one I'm transferring money from one account to another. In the other I'm transferring the responsibility for the account from one KAM to another KAM. Sharing concepts with identical names (roles) seems unintuitive to me. As Christian asked. If the similar named roles represent them same concept why are they in different contexts? For reusability I see that it could potentially be interesting to be able to use role methods for composition