What is a DCI Structure?

[Egon Elbre]

First, to clarify, this is not a question about "what is DCI". It's about the understanding of properties. My question is largerly driven by this article http://www.carlopescio.com/2012/12/ask-not-what-object-is-but.html. So read that first to understand the point of this question better.

Just a quick summary, the article talks about how we often ask "what is an object" and then define object orientation as "the dynamic creation and use of objects" or ask "what is object oriented programming" and define it terms of language features. Instead we should ask what is an "object oriented structure" (OOS) such that it is not defined in terms of language features. For example, he proposes that "OOS is one that minimizes the total size of the things you have to update, encouraging creation or deletion of new things instead".

In similar way we could define "functional structure" as a structure that tries to minimize state and mutable data through the use of pure functions. Or "DDD structure" as something that tries to minimize the mismatch between the domain model and code.

So in a similar way, what would be a "DCI structure"? What does it try to optimize, minimize, maximize?

+ egon

(PS. I know what DCI is and how it can be implemented. My goal with this question is to get some different type of discussion, that is not about "how to implement" and "what features should DCI have", "what is DCI" or "how to use DCI".)

[rune funch]

I'd say that the goal of DCI is what the goal of OO was originally. Which I don't think is expressed very well in a statement that relates to implementation such as: "OOS is one that minimizes the total size of the things you have to update, encouraging creation or deletion of new things instead".

The statement doesn't fit my understanding of OO at least. To me OO is about people first. If it weren't for people why try and represent the real world in the computer 1:1ish? The computer doesn't understand the real world. To my OO is about expressing a model in a language that the user and programmer can understand and work with. 

Usually when people use "domain model" and DDD in the same sentence they think of a domain model as related only to data. I personally don't so to avoid ambiguities. In the following I'm using domain model as a term that describes the model of a domain including both processes and information

In that respect I'd say that the proposed DDD structure is an important part of DCI. To minimize the discrepancy between the users mental model and the model found in code. Which again to me is one of the main goals of OO

-Rune

2013/9/13 Egon Elbre <egon...@gmail.com>

--
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 post to this group, send email to object-co...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/groups/opt_out.

[James O Coplien]

On Sep 13, 2013, at 10:05 , Egon Elbre wrote:

For example, he proposes that "OOS is one that minimizes the total size of the things you have to update, encouraging creation or deletion of new things instead".

I simply disagree. A good program carries information that makes it easier to modify, by providing context. Additional information implies larger size. Minimal size does not imply maintainability: anyone who has tried to maintain APL code should know that.

Anything follows from a fallacy.

[Egon Elbre]

I agree with statement, but what has it to do with the comment? It is not a goal, it's a property... Most likely if you have good OO code you don't need to modify existing classes but can either extend them or remove them without affecting other objects. So it's not minimal in size, it's minimal in changes you have to make to existing classes/objects.

I probably wrong words: "What does it try to optimize, minimize, maximize?" should be read as "What properties does DCI structure have, what are minimal, maximal?".

+ egon

[James O Coplien]

On Sep 13, 2013, at 10:53 , Egon Elbre wrote:

I agree with statement, but what has it to do with the comment? It is not a goal, it's a property... Most likely if you have good OO code you don't need to modify existing classes but can either extend them or remove them without affecting other objects. So it's not minimal in size, it's minimal in changes you have to make to existing classes/objects.

In number of changes? In rework? In deletions? In lines of code? In time taken to make the change? In time coordinating with other parts of the system?

You're asking a systems engineering question, and it's difficult to answer that without a value proposition. I think the most straightforward answers come from software engineering and its principles of coupling and cohesion. This is pretty-well established in the object literature.

The DCI community tends not to value some pseudo-encapsulation techniques that software engineering tends to like, such as inheritance. Is that in the direction of what you are looking for?

I probably wrong words: "What does it try to optimize, minimize, maximize?" should be read as "What properties does DCI structure have, what are minimal, maximal?".

I think the properties have nothing to do with minimal or maximal, any more than they have to do with blue or red. Their properties are that they articulate mental models.

[Egon Elbre]

(For some reason my answer was deleted, I'm starting to suspect Google Groups has some sort of bug)

Anyway, the comment wasn't about OO itself but rather the result of OO. In a sense this effect of mostly not needing to update a existing class/object would be a result of SOLID design, a rather useful property.

In the same way, just because it's object oriented structure doesn't exactly mean it's useful. Taking the example from the article, you could build a tensile structure that is not useful, but it would still retain it's "tensileness".

Regarding "... between the users mental model and the model found in code.", what do you mean by user? And assuming there are multiple mental models, which one of the models?

With domain model, I mean the representation of a problem domain as interpreted by a domain expert.

+ egon

[James O Coplien]

On Sep 13, 2013, at 11:19 , Egon Elbre wrote:

Anyway, the comment wasn't about OO itself but rather the result of OO. In a sense this effect of mostly not needing to update a existing class/object would be a result of SOLID design, a rather useful property.

In the same way, just because it's object oriented structure doesn't exactly mean it's useful. Taking the example from the article, you could build a tensile structure that is not useful, but it would still retain it's "tensileness".

I do not understand.

Regarding "... between the users mental model and the model found in code.", what do you mean by user? And assuming there are multiple mental models, which one of the models?

I (carefully) did not use the term: "user". We cater to the mental models of stakeholders — primarily, the programmer and end user. Programmers include architects, human interface designers, and many more. I think my emphasis tends to lie with the end user and Trygve's emphasis tends to lie with the programmer — though I think we agree that the end user needs often trump programmer needs in the event of conflict.

[Egon Elbre]

On Friday, September 13, 2013 12:10:07 PM UTC+3, Cope wrote:

On Sep 13, 2013, at 10:53 , Egon Elbre wrote:

I agree with statement, but what has it to do with the comment? It is not a goal, it's a property... Most likely if you have good OO code you don't need to modify existing classes but can either extend them or remove them without affecting other objects. So it's not minimal in size, it's minimal in changes you have to make to existing classes/objects.

In number of changes? In rework? In deletions? In lines of code? In time taken to make the change? In time coordinating with other parts of the system?

In code artifacts, so anything that is represented by code. (Obviously that isn't the only possible interpretation of OOS.)

 

You're asking a systems engineering question, and it's difficult to answer that without a value proposition. I think the most straightforward answers come from software engineering and its principles of coupling and cohesion. This is pretty-well established in the object literature.

 

Well my question is rather in the vague direction of, "if DCI would get you to a artifact space 'A', then what would get you to 'A' or near it? For that you would need to understand, what is the result of DCI and then you could work backwards to try and achieve the same/similar result in different ways.

 

The DCI community tends not to value some pseudo-encapsulation techniques that software engineering tends to like, such as inheritance. Is that in the direction of what you are looking for?

Not really, but now I'm intrigued by that direction. What do you exactly mean by "pseudo-encapsulation"? From my understanding encapsulation doesn't have much to do with inheritance per se, other than the ease of which it can destroy encapsulation.

 

I probably wrong words: "What does it try to optimize, minimize, maximize?" should be read as "What properties does DCI structure have, what are minimal, maximal?".

I think the properties have nothing to do with minimal or maximal, any more than they have to do with blue or red. Their properties are that they articulate mental models.

Yes that is the case. 

[Egon Elbre]

On Friday, September 13, 2013 12:27:27 PM UTC+3, Cope wrote:

On Sep 13, 2013, at 11:19 , Egon Elbre wrote:

Anyway, the comment wasn't about OO itself but rather the result of OO. In a sense this effect of mostly not needing to update a existing class/object would be a result of SOLID design, a rather useful property.

In the same way, just because it's object oriented structure doesn't exactly mean it's useful. Taking the example from the article, you could build a tensile structure that is not useful, but it would still retain it's "tensileness".

I do not understand.

For example, let's say you have a web application, and you have a change "introduce a new page". Ideally you want to only add code for the new screen and be done with it. But if you need to change every single class/object/thing to do it, then it probably is a poor object oriented structure, since you have a very coupled code-base. In the same idea, if you only add code for the new screen and it isn't displaying it on the screen. It is properly separated and it could be considered OO and a OOS, but it isn't useful.

So the property of "how well it minimizes artifact change" measures the end design in terms of Object Oriented Structure. If you had the perfect "object oriented" solution then that would be the lowest value you would get.

[rune funch]

2013/9/13 Egon Elbre <egon...@gmail.com>

Regarding "... between the users mental model and the model found in code.", what do you mean by user? And assuming there are multiple mental models, which one of the models?

I mean any user of the code. Whether that be compiled and executed or read. DCI allows us to represent several mental models at the same type through compaction (See the account context in the Marvin example for one such example). In the view of the private bank customer as represented in the transfer context, it's an object with a balance but seen from the view of the accountatn, as represented in the Account context it's a legder with a lot of ledger entries

 

With domain model, I mean the representation of a problem domain as interpreted by a domain expert.

A domain expert would concern her self with both processes and information wouldn't they? 

If that's the definition of a domain model then I would argue that the formulation of a structure for DDD is incorrect. DDD _force_ a diversion from the domain model into the code because DDD does not segregate between information and process aka what the system is and what the system does and thereby splitting what in the domain model is a whole  up into _independent_  parts. They come together runtime to form the whole but in code they no longer reflect the model. Which is the basis for my statement in my previous mail

-Rune

[Egon Elbre]

On Friday, September 13, 2013 1:02:04 PM UTC+3, Rune wrote:

2013/9/13 Egon Elbre <egon...@gmail.com>

Regarding "... between the users mental model and the model found in code.", what do you mean by user? And assuming there are multiple mental models, which one of the models?

I mean any user of the code. Whether that be compiled and executed or read. DCI allows us to represent several mental models at the same type through compaction (See the account context in the Marvin example for one such example). In the view of the private bank customer as represented in the transfer context, it's an object with a balance but seen from the view of the accountatn, as represented in the Account context it's a legder with a lot of ledger entries

 

With domain model, I mean the representation of a problem domain as interpreted by a domain expert.

A domain expert would concern her self with both processes and information wouldn't they?

Yes, domain expert knows how domain related processes work and what/how information is used.

 

 

If that's the definition of a domain model then I would argue that the formulation of a structure for DDD is incorrect.

Quite possibly, I do not consider myself as an expert in that area and there are definitely more reputable people who could define it better. Maybe "DDD structure when given a change in domain model it minimizes the change to the corresponding artifacts." - meaning if you have a business need/change the change will be contained in that area of the code that represents that business domain.

 

DDD _force_ a diversion from the domain model into the code because DDD does not segregate between information and process aka what the system is and what the system does and thereby splitting what in the domain model is a whole  up into _independent_  parts. They come together runtime to form the whole but in code they no longer reflect the model. Which is the basis for my statement in my previous mail

Let's say that you have a code base that doesn't have that property, of minimal discrepancy between domain model and code? Could that still be a DDD style code? IMHO you couldn't, since that would mean you don't have ubiquitous language and hence no DDD.

From what I know, it seems that DDD concerns more about separating the domain into sub-domains and bounded contexts therefore giving you the independent parts. Since after "reaching ubiquitous language" each domain and term is well defined inside its bounded context, which also means you have well defined things that have meaning in domain model.

+ egon

[rune funch]

2013/9/13 Egon Elbre <egon...@gmail.com>

Let's say that you have a code base that doesn't have that property, of minimal discrepancy between domain model and code? Could that still be a DDD style code? IMHO you couldn't, since that would mean you don't have ubiquitous language and hence no DDD.

Where I work almost all our process span multiple subdomains. It's impossible to model those processes as one whole when using DDD because I would have to model the part of the whole that pertains to subdomain A as a part of that subdomain and similar for those parts that belongs to subdomain B. I simply have no way of modelling the process as a whole if it spans multiple subdomains therefor IMHO DDD forces you _away_ from the process part of the model. trying to explain this to a DDD evangelist (which I once was my self becauseI hadn't met DCI yet) is like trying to explain the beauty of a rainbow to a (color)blind. The first several attempts Cope made to get me interested in DCI was silently acknoewledged with "yeah yeah but that's why I have DDD and/or GoF patterns"

-Rune

[Egon Elbre]

On Friday, September 13, 2013 1:45:40 PM UTC+3, Rune wrote:

2013/9/13 Egon Elbre <egon...@gmail.com>

Let's say that you have a code base that doesn't have that property, of minimal discrepancy between domain model and code? Could that still be a DDD style code? IMHO you couldn't, since that would mean you don't have ubiquitous language and hence no DDD.

Where I work almost all our process span multiple subdomains. It's impossible to model those processes as one whole when using DDD because I would have to model the part of the whole that pertains to subdomain A as a part of that subdomain and similar for those parts that belongs to subdomain B. I simply have no way of modelling the process as a whole if it spans multiple subdomains therefor IMHO DDD forces you _away_ from the process part of the model.

Because I have no clear example, I'm not able to properly comment on this problem. Taking a wild stab, but isn't that what SAGAs/events try to solve? Also, I'm not quite clear how would DCI be any different, especially when domains are distributed?

 

trying to explain this to a DDD evangelist (which I once was my self becauseI hadn't met DCI yet) is like trying to explain the beauty of a rainbow to a (color)blind.

By no means I would consider a DDD proponent. It has good ideas, but as with anything there are problems and not suitable for everything.

 

The first several attempts Cope made to get me interested in DCI was silently acknoewledged with "yeah yeah but that's why I have DDD and/or GoF patterns"

Why I'm hesitant about DCI is that it presupposes the model that the "user"/"programmer" has is the "correct" or "best" one. I get how it maps directly the model and how it is able to better represent collaboration. But it doesn't force your model to be simpler; although it makes you able to write the model and interaction from different perspectives without coupling them all together.

 

-Rune

[James O Coplien]

On Sep 13, 2013, at 10:47 , Egon Elbre wrote:

Object Oriented Structure and Object Orientation are different things... 

Not in DCI. DCI is about object orientation. Object orientation is about a network of objects working together to implement some system operation.

If you look at some of my talks about form, architecture, patterns and DCI you may gain another insight into this.

[Egon Elbre]

I've looked most of the talks by you :)

Anyway, In those terms I would say the "object oriented structure" is the network and how it looks like and the artifacts involved, and object orientation encompassing the process, your goals how you get to such network and it also includes the structure.

[Matthew Browne]

Hi Egon,
Interesting questions...I'm wondering what prompted them. Was it just the paper you read, or is it more of a general interest in somehow quantifying the benefits of DCI in order to compare it with other approaches? i.e. to better understand its strengths and weaknesses in terms of metrics and not only philosophy? Of course, by relying on metrics too much it's possible to lose important human elements, and the major point of DCI is to put the focus back on people and mental models rather than so much on technical features. But metrics can be valuable too.

Sorry if I'm misconstruing your point of interest here, I just thought that maybe getting to the root behind your question could be helpful for discussion.

[Egon Elbre]

On Saturday, September 14, 2013 7:48:09 AM UTC+3, Matthew Browne wrote:

Hi Egon,
Interesting questions...I'm wondering what prompted them. Was it just the paper you read, or is it more of a general interest in somehow quantifying the benefits of DCI in order to compare it with other approaches? i.e. to better understand its strengths and weaknesses in terms of metrics and not only philosophy? Of course, by relying on metrics too much it's possible to lose important human elements, and the major point of DCI is to put the focus back on people and mental models rather than so much on technical features. But metrics can be valuable too.

Sorry if I'm misconstruing your point of interest here, I just thought that maybe getting to the root behind your question could be helpful for discussion.

Well, partly yes to all of them. It's about understanding better DCI and the artifact space it generates and not just compare it to other approaches, maybe also derive new approaches based on that information. e.g.

function Context(bear, lion){

// role bindings

var Bear = bear, Lion = lion;

// role methods

function Bear_fight(){

Bear.say("roar...");

Lion.say("ouch...")

}

Bear_fight();

}

This is a simple example that demonstrates a similar approach to DCI, but it is not DCI. But it does provide a similar artifact space, it's more cumbersome to type, and it's easily write-able in most languages available without any "magic transformations". In a similar way, how you can do objects in pure C. But it requires some writing conventions (when calling role method you type it a certain way). Also programmers will understand this code without much effort.

So would this exhibit the same benefits as DCI? For that we would understand exactly what are the benefits, not just the process but also the end result. Code is read 10x more than it's written so I would consider the end result more important. If you say that the technical features aren't important, would this be considered as a DCI style?

Furthermore when you get DCI Structure you can analyze what is different from other styles, how will it behave when you modify the spec, how well it tolerates bugs, what if you need to add/remove/integrate something etc. I.e. if you know what properties does the DCI Structure has, you can try to predict how it would behave given some changes, without actually writing large amounts of code.

[Trygve Reenskaug]

I agree, DCI is about people first, but not last. The user's mental model shall conform with the programmer's design that shall conform with the code. Cope and I are working on an article where objects and objects structures play an important part. This post is based on the latest draft. I have removed everything I didn't feel was essential for this thread, but the post is still pretty long..

The article defines the DCI object. It offers four basic properties that are essential to the DCI paradigm:

1. State Like a computer, the DCI object has memory called its attributes. Think of an object as a database record that is encapsulated within the object boundary.
2. Behavior Like a computer, the DCI object can process data with its methods. Think of them as local procedures that are only visible within the object.
3. Encapsulation Like a computer, a DCI object is encapsulated within an abstraction boundary. The object presents a message interface to its environment just as a computer presents an instruction repertoire. The actual realization in software or hardware is not visible outside the object’s encapsulation boundary. Different objects may invoke different methods for the same message, this is called inclusion polymorphism and makes the distinction between message and method crucial for the understanding of an object system.
4. Identity Like a computer, a DCI object has a unique and immutable identity. This is essential for reasoning about networks of collaborating objects.
5. Communication Like a computer, a DCI object can collaborate with other objects through message interaction. Communication is now a first class citizen of programming.

Wikipedia defines: “Abstractions may be formed by reducing the information content of a concept or an observable phenomenon, typically to retain only information which is relevant for a particular purpose”.[

The class is the dominating abstraction on objects. It retains property 1. and 2 while it ignores property 4. and 5. The class abstraction is used to describe the static properties of a system; what the system IS.
 DCI also see the object in context with other objects. The role abstraction retains property 4 and 5 while it ignores 1 and 2. The role abstraction is used to describe the dynamic properties of a system; what the system DOES.

Property 3., encapsulation, marks the boundary between the two abstractions; the class is on the inside and the role is on the outside of this boundary. Encapsulation also  supports recursion. The inside of an object can be anything. The object can be a DCI Context that encapsulates roles and system behavior. Or it can be a state machine, a Petri net, a database access, or whatever. This means that DCI supports multi-paradigm design.

In its introduction, GOF's "Design Patterns" book defines two important structures:

• An object-oriented program's runtime structure often bears little resemblance to its code structure. The code structure is frozen at compile-time; it consists of classes in fixed inheritance relationships.
• The runtime structure consists of rapidly changing networks of communicating objects.

GOF couldn't deal with the second:

• …, it's clear that code won't reveal everything about how a system will work.

So my long answer to the question: "What is a DCI Structure?" is that there are two. Bot are structures of DCI objects. In the first, the objects are represented by their class abstraction. In the second, the objects are represented by their role abstraction.



On 2013.09.13 10:18, rune funch wrote:

...

[rune funch]

Den 14/09/2013 kl. 10.50 skrev Egon Elbre <egon...@gmail.com>:

function Context(bear, lion){

// role bindings

var Bear = bear, Lion = lion;

// role methods

function Bear_fight(){

Bear.say("roar...");

Lion.say("ouch...")

}

Bear_fight();

}

To me there's no role methods in your code. Theoretically a context could be without role methods but I guess that's not the point here. Bear_fight is not related to a specific object (other than the context) and in the respect of being free floating in its execution environment it's more like a procedure than a method. So the comparison here is to me one that surface from time to time and I guess has been around ever since OO started gaining momentum: what does object orientation add that we can't get with procedural programming following a specific set of (naming) conventions?

[James O Coplien]

On Sep 14, 2013, at 12:55 , rune funch wrote:

To me there's no role methods in your code.

... so it doesn't fit my mental model if I'm an analyst, an end user, or a bear or a lion. It fits only if I'm a programmer.

[Andreas Söderlund]

But does anyone else but the programmer care at compile-time?

2013/9/14 James O Coplien <jcop...@gmail.com>

On Sep 14, 2013, at 12:55 , rune funch wrote:

To me there's no role methods in your code.

... so it doesn't fit my mental model if I'm an analyst, an end user, or a bear or a lion. It fits only if I'm a programmer.

--

[James O Coplien]

On Sep 14, 2013, at 1:48 , Andreas Söderlund wrote:

But does anyone else but the programmer care at compile-time?

The programmer's thought process shapes the end user experience. If the programmer is not thinking in that mental model, expressing it in the code, and shaping the program to fit the end user experience, you'll end with an unusable program.

The code is, of course, an encoding (read: mapping) of the forms of the end user experience, so the translation is marred by the mental models suitable to the technology. Just as an artist captures emotion in shaped clay, a programmer captures end user mental models in shaped bytes. Neither in the case of the clay nor of the bytes is the medium the focus of the care: it should be lodged in the unconscious mind and in the dexterity of fingers that work with instinct. A programmer enamored with his language is no better than an artist who celebrates only his material. This is why DCI is solidly post-modern and we don't articulate it in the tools of programmers: type or retract theory, or formal computational models.

[Egon Elbre]

On Saturday, September 14, 2013 1:55:51 PM UTC+3, Rune wrote:

Den 14/09/2013 kl. 10.50 skrev Egon Elbre <egon...@gmail.com>:

function Context(bear, lion){

// role bindings

var Bear = bear, Lion = lion;

// role methods

function Bear_fight(){

Bear.say("roar...");

Lion.say("ouch...")

}

Bear_fight();

}

To me there's no role methods in your code. Theoretically a context could be without role methods but I guess that's not the point here. Bear_fight is not related to a specific object (other than the context) and in the respect of being free floating in its execution environment it's more like a procedure than a method.

It's related implicitly by name to the role, but yes, it's not a role method explicitly. So...

Bear.fight = function(){

this.say("roar");

Lion.say("ouch...")

}

Bear_fight = function(){

Bear.say("roar");

Lion.say("ouch...")

}

The first one would be related to the role and the second wouldn't? To me it looks just like syntax sugar, in other words, the benefit comes from thinking in terms of data, context, interaction, roles... not thinking in terms of the syntax itself.

So the comparison here is to me one that surface from time to time and I guess has been around ever since OO started gaining momentum: what does object orientation add that we can't get with procedural programming following a specific set of (naming) conventions?

Yes, that example is of the same sorts. And just to be clear, I'm not saying that such syntax isn't useful, it's nice to have such sugar on top of ideas and force the ideas to be explicit.

[Egon Elbre]

On Saturday, September 14, 2013 12:42:40 PM UTC+3, trygve wrote:

I agree, DCI is about people first, but not last. The user's mental model shall conform with the programmer's design that shall conform with the code.

I'm not saying that it isn't important, but there are other things related to it as well, e.g. the end result. Also my concern still stands that the user's mental models aren't always the best model to choose. Teaching other people taught me that there are significant differences how people perceive the world, so it means that if there are multiple interpretations we should choose or have to deal with multiple such models. Obviously, it's not possible to represent all possible mental models, so we have to make some decision which model to use.

Cope and I are working on an article where objects and objects structures play an important part. This post is based on the latest draft. I have removed everything I didn't feel was essential for this thread, but the post is still pretty long..

The article defines the DCI object. It offers four basic properties that are essential to the DCI paradigm:

1. State Like a computer, the DCI object has memory called its attributes. Think of an object as a database record that is encapsulated within the object boundary.
2. Behavior Like a computer, the DCI object can process data with its methods. Think of them as local procedures that are only visible within the object.
3. Encapsulation Like a computer, a DCI object is encapsulated within an abstraction boundary. The object presents a message interface to its environment just as a computer presents an instruction repertoire. The actual realization in software or hardware is not visible outside the object’s encapsulation boundary. Different objects may invoke different methods for the same message, this is called inclusion polymorphism and makes the distinction between message and method crucial for the understanding of an object system.
4. Identity Like a computer, a DCI object has a unique and immutable identity. This is essential for reasoning about networks of collaborating objects.
5. Communication Like a computer, a DCI object can collaborate with other objects through message interaction. Communication is now a first class citizen of programming.

Wikipedia defines: “Abstractions may be formed by reducing the information content of a concept or an observable phenomenon, typically to retain only information which is relevant for a particular purpose”.[

The class is the dominating abstraction on objects. It retains property 1. and 2 while it ignores property 4. and 5. The class abstraction is used to describe the static properties of a system; what the system IS.
 DCI also see the object in context with other objects. The role abstraction retains property 4 and 5 while it ignores 1 and 2. The role abstraction is used to describe the dynamic properties of a system; what the system DOES.

Property 3., encapsulation, marks the boundary between the two abstractions; the class is on the inside and the role is on the outside of this boundary. Encapsulation also  supports recursion. The inside of an object can be anything. The object can be a DCI Context that encapsulates roles and system behavior. Or it can be a state machine, a Petri net, a database access, or whatever. This means that DCI supports multi-paradigm design.

I do like these properties. As a side note, it would be definitely interesting to look at Component-Entity-System, Behavior-Object-Tag, Functional and Actor model in terms of such properties.

 

In its introduction, GOF's "Design Patterns" book defines two important structures:

• An object-oriented program's runtime structure often bears little resemblance to its code structure. The code structure is frozen at compile-time; it consists of classes in fixed inheritance relationships.

Would you even want to describe the whole system structure in its code structure? I would rather describe how to build the system structure.

• The runtime structure consists of rapidly changing networks of communicating objects.

GOF couldn't deal with the second:

• …, it's clear that code won't reveal everything about how a system will work.

I don't think it's even possible to reveal how a system will work... the proof is always in the pudding i.e. if you pull out your RAM while your program is running, how could the behavior be revealed in the code. I think it can't, because the only time you have the full information about the system is when it's actually running.

So my long answer to the question: "What is a DCI Structure?" is that there are two. Bot are structures of DCI objects. In the first, the objects are represented by their class abstraction. In the second, the objects are represented by their role abstraction.

Is "role" an abstraction? I don't see roles as something abstract, but something very concrete in a specific context.

IMHO. this separation that roles + context gives is very good indeed. I.e. a single mental model, whichever, is very strictly tied to particular context; so given a change in the model, I expect the code change to be contained in the context. This of course would come at the cost of "reusability" (since you can't share roles between different contexts). It seems that DDD/OO do somewhat a different trade-off, by providing more reuse and less encapsulation.

[rune funch]

Den 14/09/2013 kl. 14.06 skrev James O Coplien <jcop...@gmail.com>:

> A programmer enamored with his language is no better than an artist who celebrates only his material. This is why DCI is solidly post-modern and we don't articulate it in the tools of programmers: type or retract theory, or formal computational models.

+1
and thanks for putting prose to thoughts I myself have been unable to express

[James O Coplien]

On Sep 14, 2013, at 3:24 , Egon Elbre wrote:

 Obviously, it's not possible to represent all possible mental models,

First, we don't want to do that. We need only the mental models of the stakeholders.

Second, can you prove your statement true? It's a pretty strong and unjustified claim.

[Egon Elbre]

On Saturday, September 14, 2013 9:24:40 PM UTC+3, Cope wrote:

On Sep 14, 2013, at 3:24 , Egon Elbre wrote:

 Obviously, it's not possible to represent all possible mental models,

First, we don't want to do that. We need only the mental models of the stakeholders.

Still one person could easily come up with 3 models and given N stakeholders and you still get a lot of models.

  

Second, can you prove your statement true? It's a pretty strong and unjustified claim.

Yes, it was wrong, too strong and unjustified.

Nevertheless, I'll try anyway to prove it to some extent. Assuming you have 10 stakeholders, and each has a multiple models with slight variations, then we would end up with, lets say 30 different mental models. Of course not all of them are perfect and have mistakes in them. But, would it be possible to represent all of them, probably yes... in a way that all work perfectly together, likely not. At large enough scale the rules of different models end up in conflict, so you would need something to resolve the conflict. Which would require some model that resolves the conflict. Which brings you to the start, that you have multiple models of that may end up conflicting with each other. Of course it is very likely that it will converge and that some of the mental models are discarded outright. Having multiple models that conflict with each other is an easy way to bugs.

So the problem with mental models is that you can have tiny variations, i.e. when do you consider two models to be equal. So assuming you can have N variations and you want to represent it, you would still need to choose some particular version of it. So does it matter in the long run, maybe not, but still it's not practical to represent all possible tiny variation of models.

:)

[Matthew Browne]

On 9/14/13 3:11 PM, Egon Elbre wrote:
> So the problem with mental models is that you can have tiny
> variations, i.e. when do you consider two models to be equal. So
> assuming you can have N variations and you want to represent it, you
> would still need to choose some particular version of it. So does it
> matter in the long run, maybe not, but still it's not practical to
> represent all possible tiny variation of models.
>
> :)

I don't see representing all the possible minor variations in mental
models as being the goal. I think the goal is to determine the roles
according to concepts that are common to everyone's mental model, or
perhaps those that are common to everyone plus a few more that exist
only in the programmers' mental models...but the latter should only be
necessary where the users' mental models are too vague to represent some
significant internal object behavior / implementation detail. That's not
to say that all the stakeholders and programmers would see the same
roles from the beginning - far from it. Rather, by working together and
better understanding each other's mental models, a shared mental model
is formed based on shared concepts from the real world.

Trygve put this excellently in a recent thread:
> I don't see DCI as a method for realizing any odd domain model that
> initially may be in the user's mind. The lean principle "everybody,
> all together, all the time" says that user and programmer together
> shall collaborate to construct a new mental model that extends the
> initial domain model with an explanation of how the new system works.
> The user is an active member of the development team and the
> programmer creates a system that will feel like an extension of the
> user's mind - no surprises.
https://groups.google.com/d/msg/object-composition/e6K7KhKkdnM/YF9voPk_lmgJ

Perhaps an example will help here...I recently worked on a class
registration system for afterschool classes that allowed parents to
register their students for classes online. When I have more time I'll
post several of the full use cases and code because I have some
questions and I think it might make for good discussion, but just to
illustrate what I'm talking about here...

In the "Select Classes" use case (which is part of the larger
summary-level use case "Register Students for Classes"), the three main
roles are (Shopping)Cart, ClassCatalog, and Registrar. (ClassCatalog and
Registrar are both played by repository-like objects for managing
classes and class registrations, respectively.)

The concepts of a shopping cart, class catalog, and a registrar are all
familiar concepts which the users, stakeholders, and programmers of this
system all understand. Another programmer might very well have designed
the roles in a different way, but if they were doing good DCI
programming, there would be some definite similarities to the mental
model behind my design, because of the shared concepts that form the
basis of it. Maybe there would be other roles instead of ClassCatalog
and Registrar, but those roles would still be about looking up classes,
determining eligibility, and registering for them, regardless of what
the roles are named or the exact way in which they interact with each
other. The important thing is the end result of readable code that all
the current and future programmers can easily understand, based on a
mental model that makes sense to programmers, stakeholders, and end users.

[Egon Elbre]

Yes, which was my initial point that you still need to choose and adjust the model somehow and not implement all of the models. To describe it then as a "users model" would be wrong; to describe it as a programmer mental model would be also wrong. So in DDD they explained it explicitly as the development of ubiquitous language, understanding that is created together and well defined.

[James O Coplien]

On Sep 14, 2013, at 10:14 , Matthew Browne wrote:

> I don't see representing all the possible minor variations in mental models as being the goal.

Right. There are time-honored techniques from contextual design, user profiling and cognitive psychology to create models that are useful to the programmer. I think a lot of programmers can come to these models intuitively. I frequently become concerned that too many programmers *believe* they can come to these intuitively but they get caught up in nerd-think.

In any case, I suggest withholding criticism of mental-model building unless you are well-read and skilled in the application of these tools. When I teach domain analysis, I teach commonality and variability analysis: these can be taken as prime foundations of human cognition. Of course one weeds out the tiny variations, and it is just plain stupid to let the details dominate the design. Of course they inform the design, and this is why it takes good domain expertise to be able to drive to the right designs. That's why we have "everybody, all together, from early on."

And, Matthew, thanks for finding and reiterating Trygve's comment from a previous thread. Priceless and exactly suitable to this issue.

On Sep 14, 2013, at 11:18 , Egon Elbre wrote:

> Yes, which was my initial point that you still need to choose and adjust the model somehow and not implement all of the models.

Egon, I'd advise you to get the big picture instead of sweating the details. In the end, there are not many models to be reconciled, but a single gestalt that comes from the team process of collective understanding. Your comments seem to be typical of a solo virtuoso nerd stance rather than of a team that works with a constituency to understand needs. In the end, you need to start with that before moving on to the mechanics of roles, classes, objects, and interactions. Based on what you've contributed here I think you need to go a long way in these direction before you can grok the important stuff about DCI. I suggest hanging out with some analysts and HCI people for a while to gain some perspective into this world.

[Egon Elbre]

On Sunday, September 15, 2013 11:29:53 AM UTC+3, Cope wrote:

On Sep 14, 2013, at 10:14 , Matthew Browne wrote:

> I don't see representing all the possible minor variations in mental models as being the goal.

Right. There are time-honored techniques from contextual design, user profiling and cognitive psychology to create models that are useful to the programmer. I think a lot of programmers can come to these models intuitively. I frequently become concerned that too many programmers *believe* they can come to these intuitively but they get caught up in nerd-think.

In any case, I suggest withholding criticism of mental-model building unless you are well-read and skilled in the application of these tools. When I teach domain analysis, I teach commonality and variability analysis: these can be taken as prime foundations of human cognition. Of course one weeds out the tiny variations, and it is just plain stupid to let the details dominate the design. Of course they inform the design, and this is why it takes good domain expertise to be able to drive to the right designs. That's why we have "everybody, all together, from early on." 

 

To me there is a distinction between constructing a mental model and using a mental model. From all what I've seen the is saying is using the latter... taking quotes from Wiki, "These data implement an information structure that comes from the mental model of end users...", "A Role is a stateless programming construct that corresponds to the end user's mental model of some entity in the system." Not once in it says that it's constructed (the closest I found was "The data model is often based on an informal domain analysis." but that was deliberately trying to find such statement for 10min). When you say "corresponds to stakeholders model", it doesn't say "it's created from shared understanding of stakeholders" - to me these are different things and different approaches. Seeing that you define your things nicely, I assumed that is what you also meant.

And, Matthew, thanks for finding and reiterating Trygve's comment from a previous thread. Priceless and exactly suitable to this issue.

On Sep 14, 2013, at 11:18 , Egon Elbre wrote:

> Yes, which was my initial point that you still need to choose and adjust the model somehow and not implement all of the models.

Egon, I'd advise you to get the big picture instead of sweating the details.

I think you need to understand both, big and small details, to understand the whole picture. This was started as a "small details question" in the beginning, and I said that.

In the end, there are not many models to be reconciled, but a single gestalt that comes from the team process of collective understanding. Your comments seem to be typical of a solo virtuoso nerd stance rather than of a team that works with a constituency to understand needs.

Quite possibly it comes across that way. But, if it doesn't work at small scale, how could it work at large scale?

 

In the end, you need to start with that before moving on to the mechanics of roles, classes, objects, and interactions. Based on what you've contributed here I think you need to go a long way in these direction before you can grok the important stuff about DCI.

From what I understand the important stuff is the distinction how objects have context local behavior that is not properly addressed i.e. the need for roles to separate such behaviors. The behaviors are often associated with a specific context where they are appropriate. Essentially this would mean that the constructed model can be much more easily mapped on to the code in a way that encapsulates that context and behaviors, and doesn't inflict changes outside. So the change in a requirement/code would be properly contained and will leak less. This comes at the cost&benefit of more coupled and cohesive interaction between behaviors. The local behavior cohesion gives much better readability, although could be problematic with lots of roles like "goto" when used improperly. (+ I haven't yet figured out, how it works in a distributed and fault tolerant situation, but it seems something additional is needed for that.)

This is my current interpretation of the big picture, and please do correct it.

I suggest hanging out with some analysts and HCI people for a while to gain some perspective into this world.

Do you have some recommended reading or viewing materials (also regarding CVA)?

[James O Coplien]

On Sep 15, 2013, at 11:52 , Egon Elbre wrote:

To me there is a distinction between constructing a mental model and using a mental model.

Really? How do you avoid using the model you have in your head?

On Sep 15, 2013, at 11:52 , Egon Elbre wrote:

I think you need to understand both, big and small details, to understand the whole picture. This was started as a "small details question" in the beginning, and I said that.

You carefully articulated an argument positing that the variations prevent being able to represent the whole picture. You explicitly said that the variations cause conflict. You inferred that building such a model would cause bugs. You insisted on the models being equal.

Either you are speaking with great imprecision or you are shifting the foundations of your argument as we progress. I for one can no longer make sense of what you say and disengage from this thread. I don't think we're going to make sense of this in a written forum.

[Egon Elbre]

On Sunday, September 15, 2013 1:25:30 PM UTC+3, Cope wrote:

On Sep 15, 2013, at 11:52 , Egon Elbre wrote:

To me there is a distinction between constructing a mental model and using a mental model.

Really? How do you avoid using the model you have in your head?

No, distinction doesn't mean you can necessarily avoid them together. Distinct simply means they are not equal.

 

On Sep 15, 2013, at 11:52 , Egon Elbre wrote:

I think you need to understand both, big and small details, to understand the whole picture. This was started as a "small details question" in the beginning, and I said that.

You carefully articulated an argument positing that the variations prevent being able to represent the whole picture. You explicitly said that the variations cause conflict.

The exact words I used were, "But, would it be possible to represent all of them, probably yes... in a way that all work perfectly together, likely not."

You inferred that building such a model would cause bugs.

So I said, if you use multiple models with tiny variations, you are likely to get conflicts. And not that the variations cause conflict, but in large enough scale you would likely end up in conflict.

 

You insisted on the models being equal.

Regarding equality I stated that "the problem with mental models is that you can have tiny variations, i.e. when do you consider two models to be equal." ... Which means that for practical purposes you don't have to consider each model different because of a tiny variation.

Either you are speaking with great imprecision

I am trying to be as precise as possible, but language is imprecise, so no matter how hard I try, I still am imprecise to some extent.

 

or you are shifting the foundations of your argument as we progress.

Yes, I'm feeling that the conversation has drifted also, but this is the nature of the current conversation. (Statements with calling out mistakes with adding corrections with pointing out new mistakes etc.) Of course, it's possible not to respond to irrelevant statements and not ask questions about them, but I think it would just leave unanswered questions.

I for one can no longer make sense of what you say and disengage from this thread. I don't think we're going to make sense of this in a written forum.

This is my view, why it went off track... (but indeed it was irrelevant to the original question). Or alternatively the thing I am trying to get across...

* The words that "These data implement an information structure that comes from the mental model of end users,  domain experts, programmers..." and similar statements are imprecise. Obviously, now I understand, that it isn't exactly, what you mean. The model is constructed by collaborating and it isn't simply a stakeholders model. In short, I interpreted these words differently than what you meant. Many of my statements were because of that different interpretation (e.g. "...  user's mental models aren't always the best model to choose.", "means that if there are multiple interpretations we should choose or have to deal with multiple such models", " Obviously, it's not possible to represent all possible mental models, so we have to make some decision which model to use.".

Obviously I'm still hoping for some corrections regarding "my understanding in the big picture", although it was very dense text with imprecision and irrelevant to the original question.

[Matthew Browne]

On 9/14/13 5:42 AM, Trygve Reenskaug wrote:

Encapsulation [...] Different objects may invoke different methods for the same message, this is called inclusion polymorphism and makes the distinction between message and method crucial for the understanding of an object system.

Trygve or Cope, I'm wondering if you could go into a little more detail on what you mean by "inclusion polymorphism" here. I looked it up on Wikipedia and it seems that it basically just means support for subtyping and method overriding.

Earlier Trygve was criticizing Java and C# (and I think C++ was implicated too) for not having good support of the distinction between method calls and message passing, which I initially thought was your point here. But it seems that "inclusion polymorphism" only provides that distinction with regard to inheritance and not in any other way (for example, intercepting method calls with method_missing in Ruby and similar features in other languages - isn't support for a feature like that really the most important distinction from ordinary Java, etc.?).

[James O Coplien]

On Sep 23, 2013, at 6:08 , Matthew Browne wrote:

Trygve or Cope, I'm wondering if you could go into a little more detail on what you mean by "inclusion polymorphism" here. I looked it up on Wikipedia and it seems that it basically just means support for subtyping and method overriding.

I think that you're basically right.

I think the term was coined by Peter Wegner back in the early OOPSLA days. (He liked to give things impressive names and to project a strong academic image, and that's what sent you hunting.)  It's important to understand that polymorphism just means "many forms." So in FORTRAN, "+" is a polymorphic operator: it works on "forms" of arguments such as INTEGER and INTEGER, REAL and REAL, REAL and INTEGER, and INTEGER and REAL. It's just that the binding of the operator (method selector) to the operation (method) is done at compile time.

Templates are another form of polymorphism: we can have many forms of std_list<element_type> in the C++ STL, depending on the type of the template argument.

There are many other ways of arranging form. In my old research I found that there are about 7 ± 2 of them (or maybe that's all I could understand at once...)

What OO people in our ignorance just call "polymorphism" is usually inclusion polymorphism. (Why they used this term I have no idea — it may have to do with the set inclusion of the sets of objects of the operands.) It means choosing the proper form (class, which is an implementation of a type) at run time, usually from a graph of classes that implement those types. So, again, contrary to popular belief, Smalltalk is an extremely strongly typed language — much more so than C++. It's just that its type system owes to inclusion polymorphism and that it is "enforced" at run time.

The whole of multi-paradigm design is based on these analyses of form, and on creating categories of form. If you move up the semantics ladder, taking those forms together with binding time, you end up with what popularly is called a paradigm in computer science. Going the other direction, to the more primitive notions of human perception, you will find that these categories of form reduce to identifying commonalities and variations. Human minds are very good at that – particularly the visual cortex and the right brain — so this "pattern matching" can be said to be the foundation of most human perception. You can take this even deeper and formalize it mathematically using symmetry groups, and even deeper using similarity groups. Now we are in the realm of cosmology and the foundations of existence itself: physicists view matter in terms of its symmetry properties. Many of the much-ballyhooed headlines in physics these days (Higgs Boson, etc.) arise from mathematical models that seek the other half of partially understood symmetry relations in subatomic phenomenæ.

But I do digress. The point is that there is something incredibly fundamental going on here. This is the stuff that's occupied my studies and thoughts over the larger part of my career since about 1993.

As an aside, I think there is much that we as a DCI community can learn from type systems. Luca Cardelli, which the Wikipedia article names as having worked with Wegner on such things, is brilliant in this area. I have considered enlisting his services once we get our act a bit more together and once there is more of a hunger for it in the community.

[Matthew Browne]

Yes, that did go down the rabbit hole a bit :) But it was very interesting! Thanks for the history lesson.

It would be great to continue the discussion on some of the deeper points you raised here, but first, I'm still not quite why the distinction between calling a method and sending a message is so important to DCI. I get that the message passing approach is the "right" way to do OO, but I don't see what the effective difference is for most DCI contexts, other than the fact that role methods can override instance methods -- which does of course rely on message passing rather than a direct method call, but it's still essentially the same idea as overriding methods in subclasses in traditional OOP.

I realize Trygve was just providing an excerpt...is this something that the paper will go into in more detail? It would be great if an example were provided of where the distinction between method call and message send matters to DCI, rather than just mentioning "inclusion polymorphism."

Don't get me wrong; I agree that the distinction is important and message passing is the way to go, but it seems to me that intercepting a message to do something other than calling the method of that name (or to add additional behavior before or afterwards) is useful in both OOP and in DCI, but not essential to make a simple DCI context work. Or perhaps Trygve only cares about inclusion polymorphism here and not any kind of fancy method interception? I should note that I'm speaking only at the usage level here, not about what might be required under the hood (by the DCI runtime or library) to make the role binding work.

Sorry if I'm being a bit obtuse on this point... :/� Thanks :)

On 9/23/13 6:39 AM, James O Coplien wrote:

On Sep 23, 2013, at 6:08 , Matthew Browne wrote:

Trygve or Cope, I'm wondering if you could go into a little more detail on what you mean by "inclusion polymorphism" here. I looked it up on�Wikipedia�and it seems that it basically just means support for subtyping and method overriding.

I think that you're basically right.

I think the term was coined by Peter Wegner back in the early OOPSLA days. (He liked to give things impressive names and to project a strong academic image, and that's what sent you hunting.) �It's important to understand that polymorphism just means "many forms." So in FORTRAN, "+" is a polymorphic operator: it works on "forms" of arguments such as INTEGER and INTEGER, REAL and REAL, REAL and INTEGER, and INTEGER and REAL. It's just that the binding of the operator (method selector) to the operation (method) is done at compile time.

Templates are another form of polymorphism: we can have many forms of std_list<element_type> in the C++ STL, depending on the type of the template argument.

There are many other ways of arranging form. In my old research I found that there are about 7 � 2 of them (or maybe that's all I could understand at once...)

What OO people in our ignorance just call "polymorphism" is usually inclusion polymorphism. (Why they used this term I have no idea � it may have to do with the set inclusion of the sets of objects of the operands.) It means choosing the proper form (class, which is an implementation of a type) at run time, usually from a graph of classes that implement those types. So, again, contrary to popular belief, Smalltalk is an extremely strongly typed language � much more so than C++. It's just that its type system owes to inclusion polymorphism and that it is "enforced" at run time.

The whole of multi-paradigm design is based on these analyses of form, and on creating categories of form. If you move up the semantics ladder, taking those forms together with binding time, you end up with what popularly is called a paradigm in computer science. Going the other direction, to the more primitive notions of human perception, you will find that these categories of form reduce to identifying commonalities and variations. Human minds are very good at that � particularly the visual cortex and the right brain � so this "pattern matching" can be said to be the foundation of most human perception. You can take this even deeper and formalize it mathematically using symmetry groups, and even deeper using similarity groups. Now we are in the realm of cosmology and the foundations of existence itself: physicists view matter in terms of its symmetry properties. Many of the much-ballyhooed headlines in physics these days (Higgs Boson, etc.) arise from mathematical models that seek the other half of partially understood symmetry relations in subatomic phenomen�.

But I do digress. The point is that there is something incredibly fundamental going on here. This is the stuff that's occupied my studies and thoughts over the larger part of my career since about 1993.

As an aside, I think there is much that we as a DCI community can learn from type systems. Luca Cardelli, which the Wikipedia article names as having worked with Wegner on such things, is brilliant in this area. I have considered enlisting his services once we get our act a bit more together and once there is more of a hunger for it in the community.

--
You received this message because you are subscribed to a topic in the Google Groups "object-composition" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/object-composition/H1yrn9Aehkg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to object-composit...@googlegroups.com.

[James O Coplien]

There is too much imprecision in your question for me to answer precisely. For example, C++ does not have message passing but you can still do a fair representation of DCI.

The important part of DCI is that the method for a given method selector is compile-time knowable (in C++ terms, the binding from a member function invocation to its member function is compile-time knowable).

I think I can talk about DCI without using the term "method" (if someone disagrees, let me know) but it gets into language-specific details that are probably confusing to most.

On Sep 24, 2013, at 3:58 , Matthew Browne wrote:

Yes, that did go down the rabbit hole a bit :) But it was very interesting! Thanks for the history lesson.

It would be great to continue the discussion on some of the deeper points you raised here, but first, I'm still not quite why the distinction between calling a method and sending a message is so important to DCI. I get that the message passing approach is the "right" way to do OO, but I don't see what the effective difference is for most DCI contexts, other than the fact that role methods can override instance methods -- which does of course rely on message passing rather than a direct method call, but it's still essentially the same idea as overriding methods in subclasses in traditional OOP.

I realize Trygve was just providing an excerpt...is this something that the paper will go into in more detail? It would be great if an example were provided of where the distinction between method call and message send matters to DCI, rather than just mentioning "inclusion polymorphism."

Don't get me wrong; I agree that the distinction is important and message passing is the way to go, but it seems to me that intercepting a message to do something other than calling the method of that name (or to add additional behavior before or afterwards) is useful in both OOP and in DCI, but not essential to make a simple DCI context work. Or perhaps Trygve only cares about inclusion polymorphism here and not any kind of fancy method interception? I should note that I'm speaking only at the usage level here, not about what might be required under the hood (by the DCI runtime or library) to make the role binding work.

Sorry if I'm being a bit obtuse on this point... :/  Thanks :)

On 9/23/13 6:39 AM, James O Coplien wrote:

On Sep 23, 2013, at 6:08 , Matthew Browne wrote:

Trygve or Cope, I'm wondering if you could go into a little more detail on what you mean by "inclusion polymorphism" here. I looked it up on Wikipedia and it seems that it basically just means support for subtyping and method overriding.

I think that you're basically right.

I think the term was coined by Peter Wegner back in the early OOPSLA days. (He liked to give things impressive names and to project a strong academic image, and that's what sent you hunting.)  It's important to understand that polymorphism just means "many forms." So in FORTRAN, "+" is a polymorphic operator: it works on "forms" of arguments such as INTEGER and INTEGER, REAL and REAL, REAL and INTEGER, and INTEGER and REAL. It's just that the binding of the operator (method selector) to the operation (method) is done at compile time.

Templates are another form of polymorphism: we can have many forms of std_list<element_type> in the C++ STL, depending on the type of the template argument.

There are many other ways of arranging form. In my old research I found that there are about 7 ± 2 of them (or maybe that's all I could understand at once...)

What OO people in our ignorance just call "polymorphism" is usually inclusion polymorphism. (Why they used this term I have no idea — it may have to do with the set inclusion of the sets of objects of the operands.) It means choosing the proper form (class, which is an implementation of a type) at run time, usually from a graph of classes that implement those types. So, again, contrary to popular belief, Smalltalk is an extremely strongly typed language — much more so than C++. It's just that its type system owes to inclusion polymorphism and that it is "enforced" at run time.

The whole of multi-paradigm design is based on these analyses of form, and on creating categories of form. If you move up the semantics ladder, taking those forms together with binding time, you end up with what popularly is called a paradigm in computer science. Going the other direction, to the more primitive notions of human perception, you will find that these categories of form reduce to identifying commonalities and variations. Human minds are very good at that – particularly the visual cortex and the right brain — so this "pattern matching" can be said to be the foundation of most human perception. You can take this even deeper and formalize it mathematically using symmetry groups, and even deeper using similarity groups. Now we are in the realm of cosmology and the foundations of existence itself: physicists view matter in terms of its symmetry properties. Many of the much-ballyhooed headlines in physics these days (Higgs Boson, etc.) arise from mathematical models that seek the other half of partially understood symmetry relations in subatomic phenomenæ.

But I do digress. The point is that there is something incredibly fundamental going on here. This is the stuff that's occupied my studies and thoughts over the larger part of my career since about 1993.

As an aside, I think there is much that we as a DCI community can learn from type systems. Luca Cardelli, which the Wikipedia article names as having worked with Wegner on such things, is brilliant in this area. I have considered enlisting his services once we get our act a bit more together and once there is more of a hunger for it in the community.

--
You received this message because you are subscribed to a topic in the Google Groups "object-composition" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/object-composition/H1yrn9Aehkg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to object-composit...@googlegroups.com.
To post to this group, send email to object-co...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/groups/opt_out.

--

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.

[Matthew Browne]

On 9/24/13 4:39 AM, James O Coplien wrote:
> The important part of DCI is that the method for a given method
> selector is compile-time knowable (in C++ terms, the binding from a
> member function invocation to its member function is compile-time
> knowable).

Thanks Jim, that clarifies things a bit; I look forward to reading the
paper which will perhaps talk about this a bit more, and will be an
interesting read in any case I'm sure :)

Now, back to this interesting discussion of symmetry...

You mentioned cosmology. With regard to the ideas of similarity and
difference...this probably isn't relevant to DCI...but I find it
fascinating that when you look closely enough at things that are
apparently distinct and different, you find that they are all made of
the same "stuff", or more precisely, everything is energy. There is much
to be said about this from a scientific perspective, and I'm not a
physicist so I'll leave the science at that, but I think that many
esoteric spiritual philosophies (or some might say "realizations" or
"understandings") are very relevant to this as well -- in particular
non-dualist philosophies such as Vedanta. These philosophies say that
everything in apparent reality that seems to be separate is really
interconnected, including us, and that we are not who we think we
are...i.e. we are not just individual minds or bodies.

If this isn't a topic of interest to members of this group, or if it's
too far afield from DCI, I'll stop there, but mainly I just want to echo
Jim's point that this goes very deep...and that it's very interesting!
Jim, I don't think you were necessarily going in the direction of
non-dualism so this is probably a tangent, but who knows what unexpected
benefits might come from reflecting on such things...

[Trygve Reenskaug]

On 2013.09.24 10:39, James O Coplien wrote:

The important part of DCI is that the method for a given method selector is compile-time knowable (in C++ terms, the binding from a member function invocation to its member function is compile-time knowable).

Really? For all methods of all kinds?? Fundamentally, not a feature of C++?

I think I can talk about DCI without using the term "method" (if someone disagrees, let me know) but it gets into language-specific details that are probably confusing to most.

I will not quarrel with language-specific details, particularly not C++ details. (AFAIK, C++ has never claimed to be object oriented in Alan Kay's sense of the term.)

My comment is about the fundamental execution model of object oriented systems, not an particular implementation. See Alan Kay's definition of 'object orientation' with objects as computers connected through a very high speed network. I

So I disagree with this a general statement. I need message and method as two different concepts; you may name them differently if you like. An observer in the inter-object space can see a that something flows from object to object and he can create a trace showing this flow during an execution: object-something-object-something-object-etc. I call the somethings for messages. You called them selectors in the top quote. The reception of a message triggers the execution of some part of the object's behavior. A method is the name I use for such a� part. Messages are only visible in the inter-object space. Methods are only visible within the object's boundary. Or with Kay's analogy: messages are visible on the communication bus, methods are visible within the computers.

There is a cause and effect relationship between message and method. Call them what you like, but I cannot see DCI with without these two fundamental concepts.

I can't see a DCI execution model without these two concepts. If there is a more fundamental execution model, I would be very grateful for learning about it.

P.S. I googled "java execution model". The first article I found was
� http://cs.wellesley.edu/~cs111/fall97/lectures/jem/jem.html
At a quick look, I see the words message and method used as I use them....

[Raoul Duke]

perhaps in other words: actors. (just because Kay's meaning of OO has
been bastardized, unfortunately.)

[James O Coplien]

I disagree.

Take CLOS, for example, which does not, I believe, use the term "method selector," but which is probably much more object-oriented in the Kay sense than Smalltalk is. (Does contemporary Smalltalk claim to be object-oriented in the Kay sense? Seems pretty class-oriented to me. If Smalltalk is object-oriented then I think C++ is.) Methods in CLOS are selected on the basis of the types of potentially all arguments. That means the method selector is something different from, and unmappable to. the "method name." I'd argue that this is more powerful than the Smalltalk model — and a much better fit for the human mental model of how the real world works.

Flavors, I think, is even more interesting.

And, as the pièce de résistance, the original Artima article by Coplien and (ahem) Reenskaug doesn't contain the phrase "method selector" even once. The only one selecting anything is the end user selecting an account.

If Smalltalk has a method selector, we can think of it as a token or register that allows us to associate execution with a particular method instance. In FORTRAN on a Harris 6024 machine that's called the I register. Does FORTRAN have method selectors?

The LOGOPOLIS virtual machine we designed (and simulated down to the gate level) at Bell Labs does method association through a hardware CAM so that method selectors are never discussed on this side of the abstraction layer. Let me posit that method selectors are — or at least should be — left on the machine side of the abstraction layer. Too much discussion about OO departs from the posture of the mental model and descends into engineering hell, which is the level to which engineers descend to understand things. You can bet your bippy that the kids using Turtles on a simulated Dynabook didn't talk about methods and method selectors, but I think that Kay would say that they represented the epitome of OO thinking.

I think that once again the discussion has gone to the level of a particular implementation (in Squeak), and maybe does so in a way that will limit languages without the term "method" to ever claim to be doing DCI. I think that would be unfortunate and elitist.

Maybe there is something here that needs to be made more precise, as O'Brien pointed out. I do think that, to do so, we'll need someone like a Luca Cardelli — unless there's someone on the list who has done research on type or retract theory and who is willing to step up to the task.

Den Sep 24, 2013 kl. 11:22  skrev Trygve Reenskaug:

On 2013.09.24 10:39, James O Coplien wrote:

The important part of DCI is that the method for a given method selector is compile-time knowable (in C++ terms, the binding from a member function invocation to its member function is compile-time knowable).

Really? For all methods of all kinds?? Fundamentally, not a feature of C++?

I think I can talk about DCI without using the term "method" (if someone disagrees, let me know) but it gets into language-specific details that are probably confusing to most.

I will not quarrel with language-specific details, particularly not C++ details. (AFAIK, C++ has never claimed to be object oriented in Alan Kay's sense of the term.)

My comment is about the fundamental execution model of object oriented systems, not an particular implementation. See Alan Kay's definition of 'object orientation' with objects as computers connected through a very high speed network. I

So I disagree with this a general statement. I need message and method as two different concepts; you may name them differently if you like. An observer in the inter-object space can see a that something flows from object to object and he can create a trace showing this flow during an execution: object-something-object-something-object-etc. I call the somethings for messages. You called them selectors in the top quote. The reception of a message triggers the execution of some part of the object's behavior. A method is the name I use for such a  part. Messages are only visible in the inter-object space. Methods are only visible within the object's boundary. Or with Kay's analogy: messages are visible on the communication bus, methods are visible within the computers.

There is a cause and effect relationship between message and method. Call them what you like, but I cannot see DCI with without these two fundamental concepts.

I can't see a DCI execution model without these two concepts. If there is a more fundamental execution model, I would be very grateful for learning about it.

P.S. I googled "java execution model". The first article I found was

  http://cs.wellesley.edu/~cs111/fall97/lectures/jem/jem.html
At a quick look, I see the words message and method used as I use them....

[Kris Leech]

No comment on if this is relevant (this is my first post), certainly very interesting, do know the "philosophy-in-a-time-of-software" Google group?

--
===========================================================
I welcome VSRE emails. Learn more at http://vsre.info
===========================================================

[Trygve Reenskaug]

Originally, this list was for newbies who were curious to learn about DCI.� A helpful community should help them across the chasm from class oriented to object oriented thinking and coding.

I haven't seen any newbies on this list lately. Perhaps they have been frightened away by the esoteric nature of the discussions. Jim created the new evolution list for the kind of discussions we have had for the last month? year? years?.� I admit I have contributed to this sad state of affairs.

One of the DCI goals is that end users shall be empowered to understand DCI programs, to be able to read the code and some may even write code. Things happen in the world around us. I have seen that there is a growing movement "teaching kids programming", [C2P]. A key question is what to teach: Fortran? C? Java?. PHP? One serious contender is MS SmallBasic. I believeDCI is a better choice because a bod can start very simple and grow to full fledged professional programming without ever changing the fundamental model.

My current task is to write an article on DCI aimed at the membership of ACM. It shall adhere to the Scientific American motto:
Never underestimate your reader's intelligence. Never overestimate your reader's prior knowledge.
My readership knows about computing seen from one angle or another. Only a minority has a computer science education. The goal is to build a powerful model of computing in the reader's mind. This means that there must be a minimum of new concepts in the article, and each of them has to be carefully explained. The article describes DCI as I see it. Some key concepts are data, information, data processing; the DCI object with its encapsulation and key class and role abstractions; representation of end user information: Data classes; representation of end user model of data processing with representation of system behavior: messages and methods. And more.

This is just an arbitrary summary. Please postpone your comments until to see the whole article. It shouldn't be long now.

I look forward to posting a draft of the article on this list and hope for a constructive and fruitful discussion.

--Trygve

On 2013.09.25 07:39, James O Coplien wrote:

I disagree.

Take CLOS, for example, which does not, I believe, use the term "method selector," but which is probably much more object-oriented in the Kay sense than Smalltalk is. (Does contemporary Smalltalk claim to be object-oriented in the Kay sense? Seems pretty class-oriented to me. If Smalltalk is object-oriented then I think C++ is.) Methods in CLOS are selected on the basis of the types of potentially all arguments. That means the method selector is something different from, and unmappable to. the "method name." I'd argue that this is more powerful than the Smalltalk model � and a much better fit for the human mental model of how the real world works.

Flavors, I think, is even more interesting.

And, as the pi�ce de r�sistance, the original Artima article by Coplien and (ahem) Reenskaug doesn't contain the phrase "method selector" even once. The only one selecting anything is the end user selecting an account.

If Smalltalk has a method selector, we can think of it as a token or register that allows us to associate execution with a particular method instance. In FORTRAN on a Harris 6024 machine that's called the I register. Does FORTRAN have method selectors?

The LOGOPOLIS virtual machine we designed (and simulated down to the gate level) at Bell Labs does method association through a hardware CAM so that method selectors are never discussed on this side of the abstraction layer. Let me posit that method selectors are � or at least should be � left on the machine side of the abstraction layer. Too much discussion about OO departs from the posture of the mental model and descends into engineering hell, which is the level to which engineers descend to understand things. You can bet your bippy that the kids using Turtles on a simulated Dynabook didn't talk about methods and method selectors, but I think that Kay would say that they represented the epitome of OO thinking.

I think that once again the discussion has gone to the level of a particular implementation (in Squeak), and maybe does so in a way that will limit languages without the term "method" to ever claim to be doing DCI. I think that would be unfortunate and elitist.

Maybe there is something here that needs to be made more precise, as O'Brien pointed out. I do think that, to do so, we'll need someone like a Luca Cardelli � unless there's someone on the list who has done research on type or retract theory and who is willing to step up to the task.

Den Sep 24, 2013 kl. 11:22 �skrev Trygve Reenskaug:

On 2013.09.24 10:39, James O Coplien wrote:

The important part of DCI is that the method for a given method selector is compile-time knowable (in C++ terms, the binding from a member function invocation to its member function is compile-time knowable).

Really? For all methods of all kinds?? Fundamentally, not a feature of C++?

I think I can talk about DCI without using the term "method" (if someone disagrees, let me know) but it gets into language-specific details that are probably confusing to most.

I will not quarrel with language-specific details, particularly not C++ details. (AFAIK, C++ has never claimed to be object oriented in Alan Kay's sense of the term.)

My comment is about the fundamental execution model of object oriented systems, not an particular implementation. See Alan Kay's definition of 'object orientation' with objects as computers connected through a very high speed network. I

So I disagree with this a general statement. I need message and method as two different concepts; you may name them differently if you like. An observer in the inter-object space can see a that something flows from object to object and he can create a trace showing this flow during an execution: object-something-object-something-object-etc. I call the somethings for messages. You called them selectors in the top quote. The reception of a message triggers the execution of some part of the object's behavior. A method is the name I use for such a� part. Messages are only visible in the inter-object space. Methods are only visible within the object's boundary. Or with Kay's analogy: messages are visible on the communication bus, methods are visible within the computers.

There is a cause and effect relationship between message and method. Call them what you like, but I cannot see DCI with without these two fundamental concepts.

I can't see a DCI execution model without these two concepts. If there is a more fundamental execution model, I would be very grateful for learning about it.

P.S. I googled "java execution model". The first article I found was

� http://cs.wellesley.edu/~cs111/fall97/lectures/jem/jem.html

At a quick look, I see the words message and method used as I use them....

--
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 post to this group, send email to object-co...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/groups/opt_out.

--
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 post to this group, send email to object-co...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/groups/opt_out.

--

Trygve Reenskaug������mailto: try...@ifi.uio.no
Morgedalsvn. 5A�������http://folk.uio.no/trygver/
N-0378 Oslo�������������http://fullOO.info
Norway���������������������Tel: (+47) 22 49 57 27

[Matthew Browne]

Hi Trygve,
I think your suggestion to keep this group beginner-friendly is a good one, but the DCI-evolution group is invitation-only, so there isn't a place for the rest of us to take more advanced discussions. I understand the rationale for wanting to keep the DCI-evolution group focused on fundamental advancements in DCI itself, so I suppose ideally a third group is in order, but I don't know if we have a large enough community to support an additional group (unless all of us current members join it). Another option might be to open up the DCI-evolution group and just have a private email list (rather than a Google group) for more technical DCI-advancement discussions.

Also, I'm not sure the nature of this list is a big factor in the number of newcomers to DCI. Unfortunately, DCI just isn't that well-known yet; I personally only discovered it by chance, on a whim to Google for alternatives to traditional MVC. You and others on this list have authored some great articles and presentations, which have been very helpful to me and others I'm sure, and more articles and videos will certainly help. But if we really want to promote greater awareness of DCI, especially to less advanced programmers, we should think about what sorts of things people are currently searching for, and where they're getting information in their effort to learn better programming techniques. For example, a beginner who's learning Ruby on Rails might buy an introductory Rails book. Wouldn't it be great if such a beginner book had a chapter on DCI? Unfortunately, I would guess that many programming book authors haven't even heard of DCI.

The other thing that would help, as has been mentioned before, is more examples, especially larger examples. I think some of the questions that have been asked on this list (including some of my own) would be more easily answered if there were larger examples to facilitate the learning process.

I'm willing to help with these efforts as my schedule allows.

[Matthew Browne]

Thanks Kris, I just applied to join the group; it looks interesting. I bet many of the members of that group would find DCI interesting as well, since it's a whole paradigm and not just a technical feature, and also has a lot to do with computing philosophy and history.

[Trygve Reenskaug]

Thanks Matthew,
A contribution to the creation of a larger example will be most welcome.

Jim: What about opening the evolution list?

On 2013.09.25 14:50, Matthew Browne wrote:

Hi Trygve,
I think your suggestion to keep this group beginner-friendly is a good one, but the DCI-evolution group is invitation-only, so there isn't a place for the rest of us to take more advanced discussions. I understand the rationale for wanting to keep the DCI-evolution group focused on fundamental advancements in DCI itself, so I suppose ideally a third group is in order, but I don't know if we have a large enough community to support an additional group (unless all of us current members join it). Another option might be to open up the DCI-evolution group and just have a private email list (rather than a Google group) for more technical DCI-advancement discussions.

---

[James O Coplien]

Den Sep 25, 2013 kl. 6:51  skrev Trygve Reenskaug:

Thanks Matthew,
A contribution to the creation of a larger example will be most welcome.

Jim: What about opening the evolution list?

How about just killing it and continue the good discussions we're having here?

[rune funch]

We originally started the evolution list to have discussions of what DCI is so as to not confuse newcommers. Aside from the discussion spured by Trygves comments to the Marvin account. It's a long time since we've had any of those decisions online and the few we've had has been on this list I vote for continueing that

(Ie I vote for ending the evolution list)

-Rune

2013/9/25 James O Coplien <jcop...@gmail.com>

--

[Trygve Reenskaug]

I reluctantly agree to discontinue the evolution list. My main reason is that discussions often start on some 'harmless' point on the composition list (where it belongs). It later escalates into a deep technical discussion, but then it's too late to move to the evolution list.
--Trygve

--