DCI + MVC: Building the context and propagating the results?

[Larry O'Brien]

Is the Context typically constructed as immutable, with all its Role members passed in at once, or is it valid to add them over time? In MVC, I would think of the selection of, say, the Source bank account, the Sink bank account, and the amount as a series of View interactions, not a single calculation. After the selection of the Source but before the other interactions, would one typically store a reference to a `TransferSource` or to an (incomplete) `TransferContext` object? 

The bank transfer examples all seem to use an immutable Context, with the Role objects passed in during construction. This has the advantage that the `Run` function is guaranteed its preconditions. On the other hand, if the determination of the Role objects is complex, and the Context is not constructed until they are fully determined, it has the disadvantage of smearing that Model responsibility into the realm of the Controllers. If, though, the Context is mutable, the `Run` function necessarily begins to become a little more complex:

void TransferContext Run()
{
        ValidatePreconditions();
        Source.TransferTo(Sink, Amount);
}  

private void ValidatePreconditions()
{
        AssertNotNull(Source);
        AssertNotNull(Sink);
        AssertNotNull(Amount);

}  ...etc...

And once the Context completes its `Run` / `DoIt` behavior, how are the results of that function propagated? If one is using an event-driven architecture, for instance, would one expect the `TransferContext.Run()` behavior to generate `TransferCompleted` and `TransferFailed` events? Or would one expect it to return a result to the Controller object and have the Controller propagate the results? (Which seems strange, since they are logically domain / Model events). 

[James O Coplien]

The rule of thumb is that all roles are bound atomically (as a transaction, as it were).

The more-or-less "canonical DCI" provides that this binding happens once near Context initialization. However, for recursive algorithms, it's possible to re-bind all the roles in the middle of a Context lifetime. I would suggest that this be done carefully and only at that critical point in tail recursion where the snake just bites the tip of its tail :-) I think Trygve does this in his front-loading example. The alternative is to implement method recursion with instance recursion on the Context, which is my preferred technique (see the Dijkstra example), in which case role-to-object binding takes place exactly once per Context instantiation.

In your particular example, I would be sympathetic if the selection of the role-playing objects were a sequential operation with prescribed ordering. However, in theory, I could choose the amount, and the accounts, in any order — a modeless and largely stateless interface. That kind of behavior doesn't lend itself well to use cases, which are sequential. So I don't think it belongs in the Context. Where it belongs — well, your mileage may vary, but it would likely be in the Controller if I were to take a stab at an answer.

If you start introducing objects into the middle of a use case, you have to assign them to a role at that point and (here's the tricky bit) you have to ensure that the use case is written in a way that it is impossible to use that role name before the binding takes place. That lands you in Turing hell, and the code becomes unreadable (i.e., you cannot reason about the safety of the binding of any role — you've added one more failure mode to worry about). The policies we've put together in DCI make this consternation unnecessary. Good discipline comes with constraints.

--
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.
 
 

[Christopher ánd Shalan Galtenberg]

Total aside, but if DCI was retitled: "Role-Playing Objects", it would take the geek world by storm.

I'm now off to play RPO for the afternoon.

To unsubscribe from this group and stop receiving emails from it, send an email to object-composition+unsub...@googlegroups.com.

[James O Coplien]

Hmmm.  I like it.

To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.

[Philippe Vaucher]

Total aside, but if DCI was retitled: "Role-Playing Objects", it would take the geek world by storm.

+1

IMHO DCI needs a better name/nomenclature. You cannot understand what DCI is about by its name, RPO is much more self-explanatory in this case.

While we are at it, I think "Context" would be better named "Algorithm" or "Use case" instead. Everytime I explain DCI to someone I have to explain that Context means Use case/Algorithm. But maybe there are rationales for this naming that gives other advantages.

Philippe

[James O Coplien]

On Jul 15, 2013, at 2:19 , Philippe Vaucher wrote:

While we are at it, I think "Context" would be better named "Algorithm" or "Use case" instead. Everytime I explain DCI to someone I have to explain that Context means Use case/Algorithm. But maybe there are rationales for this naming that gives other advantages.

Just as a nit: We already have a name for something that encapsulates an algorithm: procedure. Context has other powerful connotations that are useful here. Besides, it isn't the algorithm: it encapsulates the algorithm. It is also the locus of knowledge of role-to-object mappings. Procedures encapsulate algorithms; Contexts encapsulate more.

[Trygve Reenskaug]

I also like it . And� I do not like DCI as a name.
But "Role-Playing Objects" is very narrow, it may be better suited as a new name for the Interaction
I have been exploring another renaming:
��� true OO = static OO + dynamic OO.
but have scrapped the idea since DCI is getting pretty well known and I do not want to add confusion without an provable gain.

On 2013.07.15 12:32, James O Coplien wrote:

Hmmm. �I like it.

On Jul 15, 2013, at 12:24 , Christopher �nd Shalan Galtenberg wrote:

Total aside, but if DCI was retitled: "Role-Playing Objects", it would take the geek world by storm.

I'm now off to play RPO for the afternoon.


On Saturday, July 13, 2013 8:53:28 AM UTC-7, Cope wrote:

The rule of thumb is that all roles are bound atomically (as a transaction, as it were).

The more-or-less "canonical DCI" provides that this binding happens once near Context initialization. However, for recursive algorithms, it's possible to re-bind all the roles in the middle of a Context lifetime. I would suggest that this be done carefully and only at that critical point in tail recursion where the snake just bites the tip of its tail :-) I think Trygve does this in his front-loading example. The alternative is to implement method recursion with instance recursion on the Context, which is my preferred technique (see the Dijkstra example), in which case role-to-object binding takes place exactly once per Context instantiation.

In your particular example, I would be sympathetic if the selection of the role-playing objects were a sequential operation with prescribed ordering. However, in theory, I could choose the amount, and the accounts, in any order � a modeless and largely stateless interface. That kind of behavior doesn't lend itself well to use cases, which are sequential. So I don't think it belongs in the Context. Where it belongs � well, your mileage may vary, but it would likely be in the Controller if I were to take a stab at an answer.

If you start introducing objects into the middle of a use case, you have to assign them to a role at that point and (here's the tricky bit) you have to ensure that the use case is written in a way that it is impossible to use that role name before the binding takes place. That lands you in Turing hell, and the code becomes unreadable (i.e., you cannot reason about the safety of the binding of any role � you've added one more failure mode to worry about). The policies we've put together in DCI make this consternation unnecessary. Good discipline comes with constraints.

On Jul 13, 2013, at 5:27 , Larry O'Brien wrote:

Is the Context typically constructed as immutable, with all its Role members passed in at once, or is it valid to add them over time? In MVC, I would think of the selection of, say, the Source bank account, the Sink bank account, and the amount as a series of View interactions, not a single calculation. After the selection of the Source but before the other interactions, would one typically store a reference to a `TransferSource` or to an (incomplete) `TransferContext` object?�

The bank transfer examples all seem to use an immutable Context, with the Role objects passed in during construction. This has the advantage that the `Run` function is guaranteed its preconditions. On the other hand, if the determination of the Role objects is complex, and the Context is not constructed until they are fully determined, it has the disadvantage of smearing that Model responsibility into the realm of the Controllers. If, though, the Context is mutable, the `Run` function necessarily begins to become a little more complex:

void�TransferContext�Run()
{
��������ValidatePreconditions();
��������Source.TransferTo(Sink,�Amount);
}��

private�void�ValidatePreconditions()
{
��������AssertNotNull(Source);
��������AssertNotNull(Sink);
��������AssertNotNull(Amount);

}� ...etc...

And once the Context completes its `Run` / `DoIt` behavior, how are the results of that function propagated? If one is using an event-driven architecture, for instance, would one expect the `TransferContext.Run()` behavior to generate `TransferCompleted` and `TransferFailed` events? Or would one expect it to return a result to the Controller object and have the Controller propagate the results? (Which seems strange, since they are logically domain / Model events).�

--
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-composition+unsub...@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.

�
�

--
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

[Larry O'Brien]

I want to highlight something that's coming into focus for me, which is that the combination of DCI & MVC makes the role of the Controller clearer in terms of "User Experience":

On Saturday, July 13, 2013 10:53:28 AM UTC-5, Cope wrote:

... I could choose the amount, and the accounts, in any order — a modeless and largely stateless interface. That kind of behavior doesn't lend itself well to use cases, which are sequential. So I don't think it belongs in the Context. Where it belongs — well, your mileage may vary, but it would likely be in the Controller if I were to take a stab at an answer....

And in "Lean Architecture," Figure 7.3 has as a *precondition* to the "Move Money and Do Accounting Habit" :

A valid Source Account and Destination Account have been identified and the amount to be transferred is known.

When I wrote my question I skated past that, because I am used to *debating* whether such things are part or not of a use-case, because I'm used to defining use-case boundaries using the question "Is it part of the user's intention?" 

*BUT* I've been dissatisfied with that, because UX is an area where the end-users are *not* domain experts ("Can you just add another button that allows me to set that?...And then I go to this screen and put in the target account..."). If the UX *is* part of the use-case, then we should defer to the end-users conceptions of value, which leads to sub-optimal designs ("OK, for the next 3 days we'll teach you about screen 47 of the application, which has 342 options..."). But if it's *not* part of the use-case, without some kind of guidance such as provided by DCI, the line between Controller and Model responsibilities is muddy.  

With this answer, I see in DCI a clear architectural distinction between Controller responsibilities (UX, the order or means by which the accounts and amounts are specified, etc.) and the Context responsibilities (the configuration of roles and activation of the "Move Money and Do Accounting" use-cas).

Now, it still doesn't *solve* the problem of the end-user defining value in terms of their expectations of the user experience ("And then I go to this screen and I choose the amount by using the keypad...") but at least it makes it clearer that *that* Controller aspect is ultimately something that can be negotiated with a designer versus the Role-based aspects, where the end-user has the clearest understanding of value.

Does that make sense? 

[Risto Välimäki]

For me, DCI is an excellent name. "Role-Playing Objects" lacks Context, the absolutely essential notion about Interaction, and also still important notion for Data suggesting use of "barely smart objects" forming the data structure / foundation for a DCI application. 

Roles are also important, as the interaction between objects is defined by Roles and Role methods (within a Context!). Three letter acronyms just work better, and since you just can't leave "D", "C" or "I" out of DCI, I'd rather use "DCI" instead of "DCIR".

You could use that "Role-Playing Objects" as a subtitle for explaining the DCI a little bit:

Data, Context and Interaction

  --Role-Playing Objects

But as Trygve said, "Role-Playing Objects" its itself very narrow, and only a portion of what the DCI offers.

-Risto

2013/7/15 Trygve Reenskaug <try...@ifi.uio.no>

I also like it . And  I do not like DCI as a name.

But "Role-Playing Objects" is very narrow, it may be better suited as a new name for the Interaction
I have been exploring another renaming:

    true OO = static OO + dynamic OO.
but have scrapped the idea since DCI is getting pretty well known and I do not want to add confusion without an provable gain.

On 2013.07.15 12:32, James O Coplien wrote:

Hmmm.  I like it.

On Jul 15, 2013, at 12:24 , Christopher ánd Shalan Galtenberg wrote:

Total aside, but if DCI was retitled: "Role-Playing Objects", it would take the geek world by storm.

I'm now off to play RPO for the afternoon.


On Saturday, July 13, 2013 8:53:28 AM UTC-7, Cope wrote:

The rule of thumb is that all roles are bound atomically (as a transaction, as it were).

The more-or-less "canonical DCI" provides that this binding happens once near Context initialization. However, for recursive algorithms, it's possible to re-bind all the roles in the middle of a Context lifetime. I would suggest that this be done carefully and only at that critical point in tail recursion where the snake just bites the tip of its tail :-) I think Trygve does this in his front-loading example. The alternative is to implement method recursion with instance recursion on the Context, which is my preferred technique (see the Dijkstra example), in which case role-to-object binding takes place exactly once per Context instantiation.

In your particular example, I would be sympathetic if the selection of the role-playing objects were a sequential operation with prescribed ordering. However, in theory, I could choose the amount, and the accounts, in any order — a modeless and largely stateless interface. That kind of behavior doesn't lend itself well to use cases, which are sequential. So I don't think it belongs in the Context. Where it belongs — well, your mileage may vary, but it would likely be in the Controller if I were to take a stab at an answer.

If you start introducing objects into the middle of a use case, you have to assign them to a role at that point and (here's the tricky bit) you have to ensure that the use case is written in a way that it is impossible to use that role name before the binding takes place. That lands you in Turing hell, and the code becomes unreadable (i.e., you cannot reason about the safety of the binding of any role — you've added one more failure mode to worry about). The policies we've put together in DCI make this consternation unnecessary. Good discipline comes with constraints.

On Jul 13, 2013, at 5:27 , Larry O'Brien wrote:

Is the Context typically constructed as immutable, with all its Role members passed in at once, or is it valid to add them over time? In MVC, I would think of the selection of, say, the Source bank account, the Sink bank account, and the amount as a series of View interactions, not a single calculation. After the selection of the Source but before the other interactions, would one typically store a reference to a `TransferSource` or to an (incomplete) `TransferContext` object? 

The bank transfer examples all seem to use an immutable Context, with the Role objects passed in during construction. This has the advantage that the `Run` function is guaranteed its preconditions. On the other hand, if the determination of the Role objects is complex, and the Context is not constructed until they are fully determined, it has the disadvantage of smearing that Model responsibility into the realm of the Controllers. If, though, the Context is mutable, the `Run` function necessarily begins to become a little more complex:

void TransferContext Run()
{
        ValidatePreconditions();
        Source.TransferTo(Sink, Amount);
}  

private void ValidatePreconditions()
{
        AssertNotNull(Source);
        AssertNotNull(Sink);
        AssertNotNull(Amount);

}  ...etc...

And once the Context completes its `Run` / `DoIt` behavior, how are the results of that function propagated? If one is using an event-driven architecture, for instance, would one expect the `TransferContext.Run()` behavior to generate `TransferCompleted` and `TransferFailed` events? Or would one expect it to return a result to the Controller object and have the Controller propagate the results? (Which seems strange, since they are logically domain / Model events). 

--
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-composition+unsub...@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.
 
 

--
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]

I agree with Risto that Interaction is an essential part of DCI, but so are roles, and ideally I think "role" should be part of the name.

Consider the case of a context method that calls a method on a single role, and that role method doesn't refer to any other roles. In that case there's not really an Interaction (unless I'm misunderstanding the term), but there's still a role. Of course in almost every context there will be actual Interactions as well.

If a 4-letter acronym were ruled out, I'd almost prefer DCR (data-context-role) to DCI, but DCR already stands for "design change request" and "database change request", and DCI is generally a less overloaded acronym.

I don't think DCIR is too bad, but I'd be interested to hear if someone can think of a better name that includes the word "role" and is less narrowly focused than "role-playing objects." For now, DCI still seems best.

[James O Coplien]

How about, "Context, Roles and Usecases for Data"?

That would make some people here happy.

[Matthew Browne]

Lol, CRUD...

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/N5D3eBCvZhE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to object-composit...@googlegroups.com.

[Benjamin Scherrey]

Interactions are really what it's all about isn't it? Can't lose that. I do like pushing awareness of roles up and it's all about interactions between roles within a context, right? How about stealing Apple's habit of putting lower case letters in front of everything and getting dCIR?  :-) You can drop the 'd' if you wanna stay with being a TLA but a T.5LA works don't it?

-- Ben

--

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.
 
 

--
Chief Systems Architect Proteus Technologies

Chief Fan Biggest Fan Productions

Personal blog where I am not your demographic.

This email intended solely for those who have received it. If you have received this email by accident - well lucky you!!

[Trygve Reenskaug]

I find it interesting that in some sense the role abstraction is the dual of the class abstraction. The role abstraction says everything about the external properties af an object (identity, public message interface) while it says nothing about its inner construction. The class abstraction says  everything about  the inner construction of an object (attributes, methods) while it says nothing about its external properties.

The methodful role is the keystone of DCI, yet it is nothing when considered in isolation.

An isolated class does not make a program, an isolated  role does not make a program.
With class orientation, in some mysterious way a set of classes specifies what happens at run time.
With DCI, the context with its methodful roles explicitly  specifies what happens at run time.

DCI is the closest we have got to the notion of a program with objects.

• D is the substrate on which the program lives
• C is a program with a certain behavior .
• I is the instructions that together create this behavior

D, C, and I stand for three essential concepts. A name should either encompass all three, or it could be without connotation like 'trueOO'.

At the moment, I use DCI as the proper name and trueOO as a sales label.

--Trygve

[Cevat Serkan Balek]

Hi all,

Selling an idea is important.

Weeks ago, these three words come to my mind as (artistic) slang:

Direct Code Injection :)

dCI (as in automatives)

Of course it does not cover all aspects of DCI, but it gives an idea of the crux of the idea.

Cheers,

Cevat.

[Raoul Duke]

On Tue, Jul 16, 2013 at 10:58 PM, Trygve Reenskaug <try...@ifi.uio.no> wrote:
> I find it interesting that in some sense the role abstraction is the dual of
> the class abstraction. The role abstraction says everything about the
> external properties af an object (identity, public message interface) while
> it says nothing about its inner construction. The class abstraction says
> everything about the inner construction of an object (attributes, methods)
> while it says nothing about its external properties.

i suspect you have to qualify what programming language you are using
to define 'class' since what you wrote in my mind doesn't hold true
for Java, C#, etc.

[Trygve Reenskaug]

Of course not, since they are not really object oriented languages.  Alan Kay coined the term 'object orientation'. He defined an object as an entity that encapsulates state and behavior like a computer.  Java, C#, etc. are not object oriented in Kay's sense of the term.

«In computer terms, Smalltalk is a recursion on the notion of computer itself. Instead of dividing “computer stuff” into things each less strong than the whole--like data structures, procedures, and functions which are the usual paraphernalia of programming languages--each Smalltalk object is a recursion on the entire possibilities of the computer. Thus its semantics are a bit like having thousands and thousands of computers all hooked together by a very fast network. Questions of concrete representation can thus be postponed almost indefinitely because we are mainly concerned that the computers behave appropriately, and are interested in particular strategies only if the results are off or come back too slowly
Though it has noble ancestors indeed, Smalltalk's contribution is a new design paradigm--which I called object-oriented--for attacking large problems of the professional programmer, and making small ones possible for the novice user. Object-oriented design is a successful attempt to qualitatively improve the efficiency of modelling the ever more complex dynamic systems and user relationships made possible by the silicon explosion." [Kay-93]

This was written in 1993, but the concept was well understood in the Smalltalk group at Xerox PARC when I was there in the late seventies. We were arrogantly distinguishing between "the East Coast Approach" and "the West Coast Approach". The East Coast Approach was to see object orientation as an extension of  programming languages that was well within their conceptual boundaries. I even called C++ Fortran-999. (I said we were arrogant) The East Coasters  quite simply hadn't got it. With the West Coast Approach, we saw the real picture, of course.

When I think about objects they are ALWAYS  like computers in a network. The mainstream object is less strong than the whole; it lacks the communication aspect. In particular, I never think of the Java things as objects. They don't even know the difference between message and method and use the same word for both.

[Matthew Browne]

Trygve,
What do you think would be the best way of presenting object-oriented
programming to a total novice? I have a coworker who wants to learn
about it but only has experience with procedural programming so far.

I was originally thinking of showing him classic examples like animals
and shapes, but recent discussion on here has made me wonder if that's
the best place to start. As to programming language, although he's most
likely to need to program in PHP and Javascript (and maybe Ruby),
perhaps it would be better to suggest that he learn Smalltalk first so
he can understand message passing.

I found this Smalltalk tutorial which looks pretty good:
http://www.inf.ufsc.br/poo/smalltalk/ibm/

I'm curious, what would be your second choice of a language for
object-oriented programming, after Smalltalk? I'm not aware of many
other languages that have explicit message passing, other than
Objective-C, although admittedly I don't know much about a lot of the
languages that exist other than the ones I've worked with.

[Trygve Reenskaug]

Marvin?

[James O Coplien]

If you look at the Piagetian model of learning, you learn that you need to take people from what they know to what they don't know. Paradigm shifts are a likely exception because there's no reasonable point of initial departure.

A good way to teach new paradigms is to approach the pedagogy without dependence on any prior knowledge. If you really want to immerse people in a paradigm shift, I'd go with Actors rather than DCI.

Where you start is neither where you proceed nor where you end, and where you start is much less important than how you proceed.

DCI has too many hooks into mechanics and history to be a tabla rasa learning experience. It's more than just a computational model — because a computational model would include neither classes nor roles. I think one needs to start with the computational model, and I think Actors is one of the better packagings of these concepts.

I can explain Actors to my ten-year-old. I can't explain DCI to my ten-year-old.

So to me, the curriculum looks like this:

Learning gap                                             Teaching tool

OO Computational model                          Actors

OO Programming                                      Self

OO Design and the real world                   Simula 67

Engineering of OO programs                    Smalltalk

Compositional strategies                           DCI

Getting a job and starting to work             Java

Getting a *real* job and starting to work    C++

Programming without working                   Ruby

Working without programming                   Jacobsson use cases

Going through the Gate                             Scheme

[Matthew Browne]

So Marvin is a real object-oriented language but C# is not? I don't see how the introduction of DCI to C# gets you all the way to true OOP, given that for regular classes at least (those outside the DCI contexts), there's no real distinction between sending a message to an object and calling a method - all messages are assumed to be method calls, just as in C#.

Or am I misunderstanding the point you made earlier about C# and Java (and C++ too?) not really being object-oriented?

>--
>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/N5D3eBCvZhE/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.

--

Sent from my Android phone with K-9 Mail.
--
Sent from my Android phone with K-9 Mail.

[Matthew Browne]

Hi Jim,
Thank you for your insightful reply.

> A good way to teach new paradigms is to approach the pedagogy without dependence on any prior knowledge.
> If you really want to immerse people in a paradigm shift, I'd go with Actors rather than DCI.

I was talking about teaching my coworker the basics of OOP, not DCI (yet).

Thanks for the suggestion of using Actors as a starting point. Do you mean this meaning of Actors:

http://en.m.wikipedia.org/wiki/Actor_model

Or something else?

[rune funch]

Den 20/07/2013 kl. 18.15 skrev Matthew Browne <mbro...@gmail.com>:

> all messages are assumed to be method calls, just as in C#.

That's not entirely true for C#. You can have multicast delegates
(same message sent to multiple objects) and using the DLR you can have
entirely dynamic objects that have their methods added and removed at
runtime. That does however enforce a specific inheritance tree and
used for DCI would therefore disabled a lot of objects to play a role
which is why I personally found it unsatisfying for DCI. .NET is at
it's core class oriented but the DLR does have some real OO aspects
build in.

Is Marvin more OO than C#? I'd say yes since it makes it possible to
change the behavior of an object at runtime. This change is not an
observable change to the object ie reflection will not work for role
methods so there are still class orientation left in there. The choice
I had to make was either to allow objects of all types as potential
role player or to limit it to only those that derives from a specific
base class (that would handle reflection correctly) I chose the former
over the latter

-Rune

[Matthew Browne]

On 7/20/13 1:57 PM, rune funch wrote:
> Den 20/07/2013 kl. 18.15 skrev Matthew Browne <mbro...@gmail.com>:
>
>> all messages are assumed to be method calls, just as in C#.
> That's not entirely true for C#. You can have multicast delegates
> (same message sent to multiple objects) and using the DLR you can have
> entirely dynamic objects that have their methods added and removed at
> runtime.

Hmm...interesting. How does that compare with Ruby and other host
languages for DCI? In Ruby you have method_missing. Which languages do
you think come closest to true OO?

[Matthew Browne]

Of course method_missing doesn't let you intercept calls to methods that
do exist...seems that doing that is a bit more complicated:

http://stackoverflow.com/questions/7137238/how-can-i-intercept-method-call-in-ruby

[Trygve Reenskaug]

On 2013.07.20 18:14, Matthew Browne wrote:
> So Marvin is a real object-oriented language but C# is not? I don't
> see how the introduction of DCI to C# gets you all the way to true
> OOP, given that for regular classes at least (those outside the DCI
> contexts), there's no real distinction between sending a message to an
> object and calling a method - all messages are assumed to be method
> calls, just as in C#.

Yes, but which method? The one-to-many relationship between message and
role is caused by polymorphism. If there is no distinction beteen
message and method, why not use Fortran or Algol? It's much simpler.

[James O Coplien]

On Jul 20, 2013, at 6:14 , Matthew Browne wrote:

So Marvin is a real object-oriented language but C# is not?

Sigh. That makes me feel like I'm back in the 1980s again.

To me, the first order is how you think about the organization of things, and whether you let your mental models drive design. To me, everything below that is a Turing machine. I can write pretty good OO code in FORTRAN and perfectly good OO code in C.

However, it takes discipline and multi-disciplined experience to conventionalize that expressiveness. Most programmers aren't really professionals in the use of their tools, so they need crutches, or they feel that higher expressiveness in a programming language allows them to use less of their brain on that part of design and more of it on problem-solving. (Most programmers in language X probably ever only use at most 50% of the language and are ignorant about the details of much of the rest.) I've never seen a published result of a well-designed experiment that validates that any language is measurably better than any other, in spite of all of the mythological belief that would lead one to believe it's true.

I know that mine is a minority opinion. In the end I want a language that gets in my way as little as possible. It might surprise you that, for me, that's a toss-up between C++ and other assembly languages. Objective-C drives me nuts with its surprises as do most other class-oriented languages.

I think that the point I'm trying to make here is that it's much less about base syntax, or even base semantics, than about thinking. With macros I can probably make C code more readable than Marvin. The advantages of languages, compilers, and development environments are much more subtle that the usual arguments the pundits would have you believe and fall outside many of the issues that we usually bring to the forefront here.

That shouldn't be any more of a surprise than if I told you that conversing in French, Danish or English here would be easier for me than conversing in German, and orders of magnitude above conversing in Swahili. None of these languages is better than any other, and arguably not even more suitable to any given purpose than any of the others. I think most language expressiveness is about familiarity, and I think you'd have difficulty persuading a linguist otherwise. The familiarity links to idiomatic constructs rather than to the base grammar. Intrinsic expressiveness is a second-order effect (which makes French or Danish poetry more beautiful than English poetry).

(Sorry, couldn't help it.)

Food for thought, goring sacred cows.

[James O Coplien]

On Jul 20, 2013, at 6:39 , Matthew Browne wrote:

Thanks for the suggestion of using Actors as a starting point. Do you mean this meaning of Actors:

http://en.m.wikipedia.org/wiki/Actor_model

Yes.

Carl Hewitt was maybe closer to Alan Kay's model than Alan Kay himself :-)

[James O Coplien]

On Jul 20, 2013, at 7:57 , rune funch wrote:

Is Marvin more OO than C#?

Let's say you wanted to set up an experiment to prove that. The proof would be limited to properties of the language in ways you can decouple from variations in design method, thinking, or problem domain — if you indeed wanted to make a claim about the languages themselves.

What would be the control, the experimental, the measurement, and the success criteria?

I'm not saying that you couldn't do it, but I think I'm trying to say that the issues here are much more subtle than is going to fit within the characterizations of DCI, OO, restricted OO, and full OO that we have at hand. This is very squishy stuff and I think we need to take great care in making claims. It's really hard. I can think of an experiment that could prove that use of one of these languages would help people more rapidly understand DCI than the other would — but that is a different question than the experimental hypothesis. I can think of an experiment that could measure the relative productivity correlations of the two languages, but that again is different than the hypothesis.

Let me take a shot in the dark here and posit that one of the reasons this is difficult is that languages are static schematics whose expression completely disappears at run time, and that object orientation is about run time. There is something else — very important — that is worth studying in the context of object orientation, and that's the mapping between mental models, the code, and our model of what happens at run time. It is slowly growing on me today that there are strong parallels to this in linguistics and interpretation of texts, but they go into analyses and perspectives much different than we are using here. I take some comfort in that they take us more deeply, and more squarely, into a variety of mental models than we usually discuss here.

Do a thought experiment. Let's say that the code survived through to run time — that you could read the code in memory. That means that during "coding," at "compile time," you had to think more in terms of run-time than most languages afford today. There could be one representation of the program that mapped directly onto human cognition; there would be isomorphism (or at least homomorphism) between the mental models of the programmer, the program in memory, and what is in the source code.

I used to program that way. I still can (but I don't do it any more, partly because technology has put too many abstraction layers in place). I used to program in machine code. Not assembly code — machine code. At different times I've done this on four different kinds of machines.

Right here, without looking anything up, let me try to code up the bootstrap code to read in the boot sector from disk on a Harris 6024/6, and then branch to it and execute it. (I haven't touched a Harris machine in 34 years, so bear with me if there are errors):

00 00000000

01 62500013

02 00714500

03 05000012

04 00700500

05 00730500

06 22600005

07 00110200

10 22600005

11 21000020

12 40000000

13 00000100

14 00000020

Anyone who feels they can check up on me is welcome to do so :-)

The distance between my mental model of what the program is doing, the source code, and the "objects" at run time is very small.

Taking this the next step, using this language to write a Marvin compiler, is largely a matter of bookkeeping and association of names onto sections of code... like a Context does the bookkeeping for associating roles with objects, or role methods with roles. That in itself is hardly a paradigm shift.

Maybe the concepts of Marvin reduce the distance between these three models. That would be a good thing. For a certain way of thinking, I think it's actually true. But I think it's a subtly different question than that of asking whether the language is "more object-oriented" than X.

Second gauntlet this evening :-)

[Matthew Browne]

Hi Jim,
Inferring what you mean by various terms (which in some cases is different from how I've used them some or all of the time), I pretty much agree with everything you said. Great insights here.

One such term is "object-oriented programming language." Is there such a thing? Let's go back to Trygve's response to Raoul:

i suspect you have to qualify what programming language you are using
to define 'class' since what you wrote in my mind doesn't hold true
for Java, C#, etc.
  

Of course not, since they are not really object oriented languages.

As you have stated clearly and repeatedly, object orientation is a paradigm, and as such is not dependent on programming language. You've made the excellent point in the past that one can program in a so-called "object-oriented language" and still not be writing object-oriented code. Writing object-oriented code requires thinking in an object-oriented way.

So "object-oriented programming language" is really a misnomer. But what I understood Trygve to mean was that the idiomatic style of programming to which Java, C#, and presumably C++ lend themselves, at least if one has learned any of those languages from the official literature, is not fully object-oriented.

My real question is about what programming languages are the most natural fit for OOP. The same question could be asked about DCI (although since DCI is really just true OO, the answer is likely to be the same).

Sure, you could be thinking in an object-oriented / DCI-oriented way even if you're writing machine code. But it certainly would be a lot more difficult than writing the same program in Squeak (using Trygve's extensions), Marvin, Maroon, Scala, etc. Even if you managed to get very proficient at it, it would still make the transition more difficult for other programmers who might join or take over the project later. Comparing Marvin to machine code is an extreme example, but I think the principle holds to some degree when comparing Marvin and C#, or even between C# and C++.

Language designers have paradigms too, and their paradigm affects the design of the language and the ease of understanding how to write code in that language when following a different paradigm.

It seems like Smalltalk is the most natural fit for the object-oriented paradigm, and perhaps Objective-C as well. The other languages we've been discussing (aside from Java and C) come close, but messages aren't differentiated much from method calls: to respond to a message by doing something other than calling a method with the given name on the called class or one of its parent classes requires extra gymnastics.

Yet:

It might surprise you that, for me, that's a toss-up between C++ and other assembly languages. Objective-C drives me nuts with its surprises as do most other class-oriented languages.

I wonder why that is...is it just a matter of familiarity? As you already established, familiarity is important. I'm sure personal preference and preferred style of reasoning has something to do with it as well.

I'm not in any way trying to suggest that Smalltalk is "better" than C++. I haven't even done much programming in either, so I'd be the last person who should make any such claim, and maybe my impression of Smalltalk as being a more "natural" language for OO is off-base. But it does seem to me that for someone without your background, learning how to do real OOP and better understanding its real meaning through practice would be easier with Squeak (using Trygve's extension for the DCI parts) than with C++, and certainly than with C.

I'd be very interested to hear counter-arguments about whether a language's implementation of message passing is as important as I'm suggesting to the "naturalness" of OOP in that language.

[Matthew Browne]

Thanks again. I just started reading Carl Hewitt's 1976 paper, Viewing Control Structures as Patterns of Passing Messages.

I wonder: if object-oriented programming had instead been named actor-oriented programming, would its original meaning be better understood today?

An important part of OO is that objects have both state and behavior. The word "object" connotes state better, and "actor" connotes behavior better. But I think "actor" is closer overall, because actors in the real world (not just theater actors, but any person or agent) have attributes as well, which map to data properties. So I think the word "actor" conveys the idea of an entity with both state and behavior better than "object."

Of course, the actor model also introduces ideas not required for basic OO such as its approach to concurrency. So the term "actor-oriented programming," if used today, should include those concepts as well. But I think you're right that the actor model also conveys the essence of OO, perhaps better than other presentations of OO do.

There are also practical issues, such as the fact that "actor" in UML usually means "role," not "individual actor," which could cause confusion.

But if history weren't a concern, I think the term "actor-oriented programming" could work quite well.

--

[Matthew Browne]

Another term that could work would be "cell-oriented programming,"
taking the analogy of cells in a biological organism that collaborate to
sustain and further the goals of the organism as a whole. To quote Alan Kay:

"I thought of objects being like biological cells and/or individual
computers on a network, only able to communicate with messages."
http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en

[Matthew Browne]

And maybe an alternate term for DCI could be "collaboration-oriented
programming."

[Mircea Samoilă]

[Mircea]

I don't think the "main" problem is "how do we name it?" but rather "how do we protect the name from having its meaning change over time"

The problem with most of the terms used here is that they don't hold the "initial meaning" (intent) anymore.

Take "object-orientation" for example. You might think it means exactly the same thing to everyone, but a student just starting to program, is being taught that C# is object-oriented. Now who is he to say otherwise? From that point on any knowledge he accumulates is based on that assumption and, more importantly, his feeling about what object-oriented really means is influenced by his experience with programming in C#. By the time he gets exposed to true "object-orientation" he has to "rethink" his entire "world", studies show that people don't "rethink" entire "worlds" just to change the meaning of a "word", but rather make up "another word" and give it this new meaning. It's not that you can't rethink, but that if the right circumstances are not there you'll never actually think it's that important to do and you'll just choose the easier path.

As i've said before, i'm not a computer programmer by trade, but i am a businessman with a passion for it.

The problem is "object-orientation" doesn't mean the exact same thing anymore, or even one thing for that matter. It was never a registered protected brand. It's like having an unprotected restaurant name and when it gets popular, getting mad at the competitors using it to name their parking lot or a cookie. It takes little to no time to muddle the meaning. Then you'll be wasting your entire energy to "change" people's minds instead of using it to spread the actual meaning it was meant to have. In the long run this is attrition warfare, you'll lose because everyone is your enemy, instead of your friend. They attack you like white blood cells "knowing" beforehand that it just "means" something different to them. This gets worse when people in other "battlefields" (aka markets) use the name to brand other irrelevant stuff also. Why do you think businessmen (commanders) go to the same schools and keep strong friendships.

[Mircea]

There's only ONE perfect example of grassroots corporate branding in the programming field and that's Ruby on Rails.

Ruby was already a well established term so they registered Rails. Now everyone who want to have a book title with Rails on it they have to call this guy. He also has a visual trademark so you can tell, just by the feeling you get when looking at things, that you are in the right place… etc etc…

DCI has the same problem MVC had… it's a brilliant idea… now all we have to do is muddle it a little bit, adapt it to incoherent programming languages, drop some of it's features so that it "can make it into C#"…. Just use traits instead of this, just muddle this by doing that. Use the spoon instead of a fork. Soon all languages will be DCI compliant, but there will be so many implementations people will discard it on sight as not being what it is… brilliant… simple… concise.

So…

Brand… publish the exact initial prequisites on a .com… then just sit back and wait. Nothing else… in the meantime call other so called "object-oriented" languages out for not being able to implement such a brilliant… simple… concise idea that's easy to do in Smalltalk. (If you're also "object-oriented" why can't you do it?!)

[Mircea]

I think are very clear distinction has to be made in the name. DCI is about how people think, and not really about programming. Variants of the concept that DCI describes has been used in other fields.

You use a screwdriver to screw-drive a screw.

What Trygve R. is trying to teach us, is that, in practice(the real world), it's better to have "the ability" of the screwdriver to screw-drive modeled as a separate mental bucket (object). 

Why? Because if you don't have a screwdriver at hand and you have to get that loose screw tightened (Apollo mission, your life depends on it), you might use a knife that "fits" the peculiarities of that exact context and screw. 

The entire system is more "tolerant" of change and more importantly the thought pattern your mind has to store uses less space as it doesn't have to store the specifics (you don't wobble in self pity at not having a screwdriver when a small knife is good enough). 

This less space is what drivers Trygve's idea… the fact that in practice you'll have to do less work compared to other programming approaches thus having more time to do other things… It doesn't stop there. 

This less space, this decomposition that is in your head... if you get it in front of you, as in program using this paradigm, will enable you reuse the network of objects more easily in other projects. In the example above, you'll be able to reuse the screw-driving object with all it's methods and variables to generically rotate stuff, because that is what it really does. It is decoupled from all aspects that make it specific to context and data. Thus you'll be able to create more with less by just being creative (put stuff together, compose them any way you see fit).

*I think the real crux of the whole thing is actually something else, something less obvious. You'll be able to "describe programmatically" more detailed and more complex phenomena, essentially by identifying a larger breadth of these kinds of "objects", not just an object like a "coffee cup" but the object of "pouring" as programmatically model"able" object … Essentially adding in transformations as objects so that different cups, or any concave object for that matter can play the role of pouring into when needed.

---

What the human mind/body seems to be really good at is this kind of decomposition while it experiences the world. 

Imagine using a toothpick and some watercolor to paint thin lines on a painting. Every child can do this. How did the mind "identify" that the toothpick is capable of such an interaction. 

Not only that… suppose a "teacher" shows the child this interaction. But what is astonishing (from the point of view trained professionals) is that the child is able to extrapolate and paint with any wooden part, maybe create imprints with leafs. (This is another subject in itself, how the mind learns this initially… an how it keeps on learning)

---

[Matthew Browne]

HI Micrea,
You've made a lot of excellent points here and in your last two posts. Very interesting too. Just one comment below.

On 7/21/13 5:04 AM, Mircea wrote:

I think are�very�clear distinction has to be made�in the name.�DCI is about how people think, and not really about programming. Variants of the concept that DCI describes has been used in other fields.

You�use a screwdriver�to�screw-drive�a�screw.

What Trygve R. is trying to teach us, is that, in practice(the real world), it's better to�have "the ability" of the screwdriver to screw-drive�modeled as a separate mental bucket (object).�

Why?�Because if you don't have a screwdriver at hand and you have to get that loose screw tightened (Apollo mission, your life depends on it), you might use a knife that "fits" the peculiarities of that exact context and screw.

I like the analogy, and I agree that being able to use a less than ideal object (a knife in this case) that is still is capable of doing the job (tightening the screw) is a great benefit of having roles as code constructs in their own right.

But I think there's more than that to the answer of the why question you posed above. I think the greatest benefit is that in DCI, you no longer need to have a one-to-one mapping between roles and data objects, and the roles can be named differently than the data classes where appropriate. Instead of needing to be one-to-one, there can be one-to-many and many-to-many relationships between roles and data objects, in other words you can have multiple data objects that play the same role and/or multiple roles played by the same data object. The fact that roles are context-specific is also important. This flexibility means that the use case logic (what-the-system-does) no longer needs to be organized according to the more stable/static structure of the data model (what-the-system-is), which would usually win out as the organizing factor in any discrepancy between the two in a non-DCI OO system. A big win here is that use case logic can now be centralized (often in a single file). This has all been covered many times before, I just wanted to mention it again here because I think it's the most important answer to the question of why a representation/implementation of roles in the code (as well as contexts) is so helpful.

[James O Coplien]

On Jul 21, 2013, at 10:25 , Matthew Browne wrote:

I think the greatest benefit is that in DCI, you no longer need to have a one-to-one mapping between roles and data objects

Greatest benefit... over what?

 you can have multiple data objects that play the same role

Well, not at the same time.

[Matthew Browne]

On 7/21/13 4:30 PM, James O Coplien wrote:

On Jul 21, 2013, at 10:25 , Matthew Browne wrote:

I think the greatest benefit is that in DCI, you no longer need to have a one-to-one mapping between roles and data objects

Greatest benefit... over what?

Over a non-DCI OO system, as I said -- specifically, over having to compromise between an accurate delineation of the data model and an accurate delineation of the roles.

 you can have multiple data objects that play the same role

Well, not at the same time.

True; I think my point about the same object playing multiple roles was the stronger one. But I also like how you can use the same name for roles in different contexts, which might be played by the same data object. They're different roles, but they're conceptually similar, and as such might otherwise be stuck together in the same class in class-based programming, leading to difficulty reading use case logic.

[Trygve Reenskaug]

"conceptually similar"? It must all be in the eyes of the beholder. There's nothing, absolutely nothing, in DCI that links the roles in one context to the roles in another. A context is the  name space for its roles. Roles with the same name in a different contexts are, by definition, unrelated.

[James O Coplien]

On Jul 21, 2013, at 12:53 , Matthew Browne wrote:

So "object-oriented programming language" is really a misnomer. But what I understood Trygve to mean was that the idiomatic style of programming to which Java, C#, and presumably C++ lend themselves, at least if one has learned any of those languages from the official literature, is not fully object-oriented.

1. If by the object paradigm we mean the run-time computational model, I think that language is of little consequence. It is probably true that some languages better express rudimentary object semantics than others. But most problems of program comprehension are not at that level of expression: they are at the level of system operations.

2. "Object-oriented" is not a synonym for "good"

3. DCI does not completely solve the problem of being able to reason about system operations at run time. It still depends on conventions that are enforced by no language that I know of. Class instance methods can still be polymorphic, when means that any invocation of a non-role method on the role self leads to indeterminate behavior. By convention, such invocations are local. With discipline, such invocations are atomic and have return semantics. That's something we seem to assume, but there is nothing either in the DCI programming model or in the description of DCI that emphasizes that, let alone enforces it. In the end, it comes back to design.

My real question is about what programming languages are the most natural fit for OOP.

Define OOP, and we'll go from there. Do you take the Treaty of Orlando to be the definition? 'Cause that's what I use.

The same question could be asked about DCI (although since DCI is really just true OO, the answer is likely to be the same).

I think it may be a silly question. It's kind of in the same league as: What programming languages are the best fit for the Design Patterns? It's as if the Design Patterns were chunks of code, or a coding style. Programmers jump to that conclusion much as I fear people here are concluding about DCI. Both of them are ways of thinking about abstract, and sometimes dynamic, form. Readable code is a good consequence — in a language that already supports the Treaty of Orlando. DCI isn't going to help FORTRAN.

[Trygve Reenskaug]

On 2013.07.22 22:49, James O Coplien wrote:

Define OOP, and we'll go from there. Do you take the Treaty of Orlando to be the definition? 'Cause that's what I use.

Treaty of Orlando object definition? Unfortunately, I have never seen it.
I googled� "Treaty of Orlando" and ""Treaty of Orlando" object definition" and got an unbelievable number of dead links.
What I found had something to do with delegation and prototypes, but I did not find a definition of 'object'. It should be very interesting to see it.

I've been so deeply attached to my own notion of an object that I haven't realized it may be weird.� The following is my most recent definition taken from a draft article::

Like a computer, a true object offers three basic capabilities that are essential for representing system state and system behavior:
storing, transforming, and communicating:

1. Like a computer, the true object has memory called its attributes. Think of the object as a database record that is encapsulated within the object boundary.
2. Like a computer, the true object can transform data with its methods. Think of them as local procedures that are only visible within the object.
3. Like a computer, a true object can communicate with other objects by sending messages to them. Think of it as a universe of objects connected trough a communication bus.
   
4. Like a computer, a true object has a unique and immutable identity that lets other objects address messages to it.
5. Like a computer, a true object is encapsulated within an abstraction boundary. The object exhibits a message interface just as a computer exhibits an instruction repertoire. In both cases, the actual realization by software method or hardware is not visible outside the object�s encapsulation boundary. Different objects may employ different methods for the same message, this is called polymorphism and makes the distinction between message and method crucial for the understanding of an object system.

[Matthew Browne]

I'm glad Jim mentioned it; I hadn't heard of it either. Below is the link I found...yes, it does talk a lot about delegation and prototypes...the treaty begins on the third page:

http://web.media.mit.edu/~lieber/Lieberary/OOP/Treaty/Treaty.ps

Unless Jim is talking about something else that happened in Orlando at the same conference where the treaty was written, I think this falls short of a definition of OOP, but I do think it adds to the discussion.

--
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/N5D3eBCvZhE/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.

�
�

[Christopher & Shalan Galtenberg]

That's a truly lovely metaphor, Trygve. Inspiring, in fact.

Will be musing on it today -- as well as wondering about the limits which provide the real boundary of the definition (what should object computers not do?)

Also will be reading the Treaty, thanks for it Matthew!

On 23 July 2013 06:25, Trygve Reenskaug <try...@ifi.uio.no> wrote:

On 2013.07.22 22:49, James O Coplien wrote:

Define OOP, and we'll go from there. Do you take the Treaty of Orlando to be the definition? 'Cause that's what I use.

Treaty of Orlando object definition? Unfortunately, I have never seen it.

I googled  "Treaty of Orlando" and ""Treaty of Orlando" object definition" and got an unbelievable number of dead links.

What I found had something to do with delegation and prototypes, but I did not find a definition of 'object'. It should be very interesting to see it.

I've been so deeply attached to my own notion of an object that I haven't realized it may be weird.  The following is my most recent definition taken from a draft article::

Like a computer, a true object offers three basic capabilities that are essential for representing system state and system behavior:
storing, transforming, and communicating:

1. Like a computer, the true object has memory called its attributes. Think of the object as a database record that is encapsulated within the object boundary.
2. Like a computer, the true object can transform data with its methods. Think of them as local procedures that are only visible within the object.
3. Like a computer, a true object can communicate with other objects by sending messages to them. Think of it as a universe of objects connected trough a communication bus.
   
4. Like a computer, a true object has a unique and immutable identity that lets other objects address messages to it.

1. Like a computer, a true object is encapsulated within an abstraction boundary. The object exhibits a message interface just as a computer exhibits an instruction repertoire. In both cases, the actual realization by software method or hardware is not visible outside the object’s encapsulation boundary. Different objects may employ different methods for the same message, this is called polymorphism and makes the distinction between message and method crucial for the understanding of an object system.

[Matthew Browne]

On 7/23/13 9:25 AM, Trygve Reenskaug wrote:

The following is my most recent definition taken from a draft article::

Like a computer, a true object offers three basic capabilities that are essential for representing system state and system behavior:
storing, transforming, and communicating

I find it interesting that these are the same 3 properties that Carl Hewitt highlighted (except he used the word "processing" and not "transforming") in a video session with him I watched the other day after Jim recommended looking into Actors. Quote from the video:

"An Actor is the fun�da�men�tal unit of com�pu�ta�tion which embod�ies the 3 things � pro�cess�ing, stor�age and com�mu�ni�ca�tions � that are essen�tial to computation."

http://channel9.msdn.com/Shows/Going+Deep/Hewitt-Meijer-and-Szyperski-The-Actor-Model-everything-you-wanted-to-know-but-were-afraid-to-ask

[James O Coplien]

Hee hee :-)

On Jul 23, 2013, at 10:27 , Matthew Browne wrote:

On 7/23/13 9:25 AM, Trygve Reenskaug wrote:

The following is my most recent definition taken from a draft article::

Like a computer, a true object offers three basic capabilities that are essential for representing system state and system behavior:
storing, transforming, and communicating

I find it interesting that these are the same 3 properties that Carl Hewitt highlighted (except he used the word "processing" and not "transforming") in a video session with him I watched the other day after Jim recommended looking into Actors. Quote from the video:

"An Actor is the fun­da­men­tal unit of com­pu­ta­tion which embod­ies the 3 things – pro­cess­ing, stor­age and com­mu­ni­ca­tions – that are essen­tial to computation."

http://channel9.msdn.com/Shows/Going+Deep/Hewitt-Meijer-and-Szyperski-The-Actor-Model-everything-you-wanted-to-know-but-were-afraid-to-ask

[Mircea]

Images seem to be missing from inside the PDF.

Pe 23.07.2013, la 16:34, Matthew Browne <mbro...@gmail.com> a scris:

I'm glad Jim mentioned it; I hadn't heard of it either. Below is the link I found...yes, it does talk a lot about delegation and prototypes...the treaty begins on the third page:

http://web.media.mit.edu/~lieber/Lieberary/OOP/Treaty/Treaty.ps

Unless Jim is talking about something else that happened in Orlando at the same conference where the treaty was written, I think this falls short of a definition of OOP, but I do think it adds to the discussion.

On 7/23/13 9:25 AM, Trygve Reenskaug wrote:

On 2013.07.22 22:49, James O Coplien wrote:

Define OOP, and we'll go from there. Do you take the Treaty of Orlando to be the definition? 'Cause that's what I use.

Treaty of Orlando object definition? Unfortunately, I have never seen it.

I googled  "Treaty of Orlando" and ""Treaty of Orlando" object definition" and got an unbelievable number of dead links.

What I found had something to do with delegation and prototypes, but I did not find a definition of 'object'. It should be very interesting to see it.

I've been so deeply attached to my own notion of an object that I haven't realized it may be weird.  The following is my most recent definition taken from a draft article::

Like a computer, a true object offers three basic capabilities that are essential for representing system state and system behavior:
storing, transforming, and communicating:

1. Like a computer, the true object has memory called its attributes. Think of the object as a database record that is encapsulated within the object boundary.
2. Like a computer, the true object can transform data with its methods. Think of them as local procedures that are only visible within the object.
3. Like a computer, a true object can communicate with other objects by sending messages to them. Think of it as a universe of objects connected trough a communication bus.
   
4. Like a computer, a true object has a unique and immutable identity that lets other objects address messages to it.

1. Like a computer, a true object is encapsulated within an abstraction boundary. The object exhibits a message interface just as a computer exhibits an instruction repertoire. In both cases, the actual realization by software method or hardware is not visible outside the object’s encapsulation boundary. Different objects may employ different methods for the same message, this is called polymorphism and makes the distinction between message and method crucial for the understanding of an object system.

--
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/N5D3eBCvZhE/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.

[Trygve Reenskaug]

�

I find it reassuring.

[Matthew Browne]

Let's take the restaurant example. I know I said before it was a bit misleading because in DCI (at the implementation level) we're talking about object roles, not roles played by people (unless it's a simulation system), but the following example could be for a factory that produces food, where there is no real "chef" but rather chef-like objects in the system that tell the factory machines what to do.

Suppose we have a role called "Chef" in two different contexts, e.g.

BakingContext
{
    ...
    role Chef {
        ...
    }
    ...
}

StirFryingContext
{
    ...
    role Chef {
        ...
    }
    ...
}

Now, why would we choose the word "chef" for both? Because, as I said before, the activities involved are "conceptually similar". If there weren't any similarity, we probably wouldn't use the same word. I'm sure I could think of other examples of similar activities with the same name that are still different roles if this still isn't clear enough.

Mircea explained this very nicely in the other thread:

When you talk to someone you infer meaning from his words and language right? When i say "Spin Motor" or "Spin Hand" no language writes the first Spin differently from second Spin to indicate the actual "spinning" is different in the case of the Motor or your Hand. There are similarities, but it's not the exact same thing. Similar enough =  you write them the same way…. Too much difference = you should have chose completely different words.

Reading it backwards (and extracting something useful for code) you can't infer the difference in the "Spin" action in "Spin Motor" and "Spin Hand" you are about to take unless you take into account the entire context the word is used in. 

But the context is invisible(hidden), "Spin Motor" and "Spin Hand" have the same structure "Spin + another word" and "Spin" is written the same way. The other word "Motor" or "Hand" couldn't possibly have anything to do with "Spinning" in general… when i say "Hand" you don't think of "Spin Hand" as the precise and only action you can do with your Hand. Also there are other ways to interact with a "Motor", there are motors that don't spin, actually.

In their effort to make code more readable, Trygve and Cope have actually brought Smalltalk closer to my free understanding of language. Bringing Context into play as a definite visible object, so now i have something that i can use as a "loci" (a place) for the different meaning(s) "Spin" can take on according to what i want to "Spin". The true genius of the idea is in fusing the normal "Object" (aka Data) with its meaning-pregnant Roles in that Context at runtime essentially mimicking the word "Spin" as it takes precise meaning only when used with another word (ex: "Spin Hand") what further clarifies what exactly we are talking about here.

They essentially created what i expected all along, for code to mean something to me as a human being. Which is very valuable, if it weren't we would all be using Assembler or Byte Core directly. 

Conclusion

I used to have a word to describe this in my head, i've searched for it while writing this... "band" or "bound"

"Objects work together to achieve a common goal." should in the case of DCI be replaced with

Objects band together to achieve a meaningful goal.

Objects are bound together to achieve a meaningful goal. 

"DCI limits all permissible networks of communicating objects to networks that share common topologies" 

Essentially the system is bound to have meaning (if any was put in by the programmer :)

Take this very nice music video for example: http://vimeo.com/33293128

Why do the performers change instruments while the piece is played. Pretty good music would have come out if they kept their current ones. They do this to achieve a new role in the song… and therefore greater meaning. Now he plays the guitar and he takes care of the highs… the he switches to something else… he can reuse his talents.

Essentially we can keep coding in classic OO Smalltalk because it's actually good enough. But DCI is just a whole different piece of cake, i might go as far as to say it might bring "coding to the masses".

[James O Coplien]

On Jul 25, 2013, at 2:28 , Matthew Browne wrote:

Now, why would we choose the word "chef" for both? Because, as I said before, the activities involved are "conceptually similar". If there weren't any similarity, we probably wouldn't use the same word. I'm sure I could think of other examples of similar activities with the same name that are still different roles if this still isn't clear enough.

Mircea goes on to talk about names being important. Right. So we have a "chef" in each of these two contexts. By coincidence of the two use cases / contexts, both of these roles happen to have a method called "AdjustSeasoning". For baking, it is very well-defined as a role method that doesn't entail any class method dependencies, and is based on measuring seasonings and adding them before the cooking. In stir fry, it is an iterative process that can be continued during cooking and which entails feedback as the dish progresses.

So, what does it mean to ask what it means for a chef to adjust seasoning? You've introduced cognitive dissonance. You've made it difficult to understand the code (looking for Chef>>AdjustSeasoning now has the same problem as you would if you could factor this behavior into a class hierarchy!) One of these concepts may represent a pastry Chef and the other represent a short-order cook, yet in their respective contexts there is no reason to differentiate, so we can call each one "Chef." To avoid this problem you'd need global namespace management across the namespaces of all Contexts. That's just impossible from the perspective of Conway's Law, and it makes it unreasonable to do incremental development.

No, no, no.

[Matthew Browne]

According to my understanding of "by-the-book" DCI, it's fine to use the same name for roles (similar or not) in different contexts, as long as they can't be used from outside the context for which they were designed. I'm not talking about sharing roles.

I think it's more convenient to not have to use the role name "BakingChef" in the baking context and "StirFryingChef" in the other - they're already encapsulated in the context, so why not just call them both "Chef"?

I was simply talking about the similarity between these roles at a conceptual level.

--
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/N5D3eBCvZhE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to object-composit...@googlegroups.com.

[Andreas]

Because it's in this specific domain to separate them. Code doesn't stand for itself, it's made for a reason, so it can be reasoned about.

Having followed the list for a while now, I think I see a pattern. You Matthew are having an opinion about some part of DCI, followed by a concise explanation from Cope usually, followed by another tirade from you trying to explain that it wasn't exactly what you meant, or some adjustment of your previous post. So what is your point exactly? Everyone is entitled to an opinion, but when does it stop being related to the subject at hand? If you're looking to find your an abbreviation that you can call your own, why don't you grab one off your list and do that? Or do you want to understand (and promote) DCI, but there is something fundamental about it that you still don't grasp?

I don't want to sound harsh, only concerned about your motives and your awareness of them. If everyone is fine with these kind of discussions I'll just skim them through, no problem, but wouldn't some emerging resolution be nice, eventually? Sorry for my impatience. :)

/Andreas

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.

[Mircea]

I have to agree with James on this one. 

It's not that Matthew is wrong but there is a difference. 

Let me try to explain why:

When we say language, here or when programming, we mostly mean "the words" that we use. This "is" what we use to communicate via e-mail and coding. 

But in the real world things stand a little different. While we are in our kown world, our environment, a certain familiarity ensues. Two people standing on the same side of a room might say to one another... "Open the window!" There might be two or three windows in there but without pointing or asking which, you open the window most relevant to the part of the room you are both active in. 

In this familiar environment where the "action" takes place, a shared "world" emerges. Because you share this "practice", a way of doing things, the room has the same "color" to you both. Parts of the room are made out to be more, or less, important because you stand with your back at them. You know what the other is saying, simply because you could be him doing the same thing you are doing and he could be you. So he may choose to be less specific, as it all might seem that he is talking to himself out loud. In turn you hear his voice, and you interpret it as your own... and just open the right window. There degrees in this might happen based on your relationship to the other person, master-apprentice, two chefs, a wife and a husband, etc...

However this does not make all the windows in the room the same or that one window very special, in the general sense.

Reading this into the restaurant example, Matthew's familiarity with the situation allows him to be less concise in code. He knows the difference even though the methods before his eyes are made up of the exact same letters, so he chooses to be less precise and "encodes" this degree of familiarity he feels into what he codes. 

So it is a matter of choice. If you code alone you allow familiarity in the detriment of conciseness. 

James however, chooses to be very concise, even in this rather simple example, probably as a rule of thumb (extensive experience) which in turn shows he has dealt with unfamiliar code a lot and appreciates being able to tell things apart on sight. 

As a conclusion, in this case, the name should reflect the degrees of similarity(familiarity) and the degrees of difference(conciseness) in just the right amounts. Too much or too little of each will just confuse things. 

The good news is DCI allows both, with refactoring probably being the wrench to fix things if you happen to sway to far from the truth. 

--

[Matthew Browne]

Hi Andreas,
I think you're right about the pattern of conversion between me and Cope. As to my motives, I suppose I have 3:

1. To learn more about DCI
2. To share my insights
3. To contribute to its advancement in some way

I'm sorry that the signal to noise ratio in some of my posts is a little low; for the naming endeavor I was doing quite a bit of brainstorming to see if I could find a name that I liked that others liked as well. My thought process was: even if DCI is still the best name, surely there is at least one other name that's worthy at least of consideration.

I would love to see more interest in DCI in the larger community (as long as it doesn't get watered down or misinterpreted). To that end, anything that can make it easier to understand or avoid confusion is a good thing, and that's why I think these discussions of terminology are important. I also find them interesting and I think there has been a lot of great discussion in the naming thread, which has certainly added to my understanding of DCI.

If everyone is fine with these kind of discussions I'll just skim them through, no problem, but wouldn't some emerging resolution be nice, eventually? Sorry for my impatience. :)

I'm not sure that there's any shortcut to resolution, especially with the discussion of an alternate name for DCI. There are a lot of things to be discussed and considered.

I'm sorry that I've sometimes caused the back-and-forth to be excessive. I'm trying to do a better job of explaining what I meant correctly the first time, but often I'm surprised by Cope's responses and I feel like sometimes he and I aren't speaking the same language...but nonetheless I've gotten to understand DCI better as a result of our exchanges - those surprises when you thought you understood something are a good thing.

If I were just constantly bashing DCI, or saying I disagreed with the whole paradigm, I could understand why you would think the discussion was nonconstructive, but if anything I'm enthusiastic about DCI and agree with its principles. The similarly-named roles point was actually a compliment of DCI, not a criticism or something I thought would launch a long discussion. But others disagreed with the way I described what I was trying to compliment. My other disagreements have been mostly terminology nitpicks.

So I hope that gives you a better idea of where I'm coming from...having said all that, what do you think would make the discussion more constructive?  (I think it's somewhat constructive already, but probably less than it could be.) I'm open to ideas.

Cheers,
Matt

[Andreas]

Hello Matthew, thanks for your answer. For me, being constructive is working towards a resolution, being more and more concrete and to the point. I'm not sure if this is leading in that direction, which hints about some non-factual reasoning lurking behind the scenes. Loosely based opinions (not to mention those based purely on opinion) can drag a discussion to eternity. I would try to be as concrete and factual as possible.

About the name and public attention: Trying to get mainstream attention Rails-style for DCI, I don't know. A paradigm is so much more than convention. It took me over a year to grasp the concept, and of course, the occasional mail from Cope still rocks the foundation. :) But then I try to understand from the view of not having a direct opinion, because what is that opinion usually made from? The old paradigm.

Having some experience trying to convince people about other paradigms, that attitude seems somewhat rare, so I'm having doubts going the mainstream way. The way to a new kind of thinking is a long journey, and it takes place mostly on the inside for the individual, and "mainstream" can never be in that domain, given its flock-like properties.

So to be a bit more concrete! Name change or going mainstream: Not unless we really have to, for some reason. What do you think?

/Andreas

[Matthew Browne]

Hi Mircea,
I said "similar" - "similar" is not the same as "the same".

But similarity aside, I just want to be clear on what you're saying. Are you saying that in my example the roles in the code should be named like this:

BakingContext
    role BakingChef

StirFryingContext
    role StirFryingChef


If so, why? Since the roles are encapsulated in the context, there's no chance of a naming conflict, so why not name them as I did before:

BakingContext
    role Chef

StirFryingContext
    role Chef

They're not the same role (I never said they were), I just decided to give them the same name. What's the problem here? I figure roles in different contexts can be given similar names, or not (programmer's decision)...in the case where you can name them differently to highlight something important that's not obvious from the name of the context, maybe "not".

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/N5D3eBCvZhE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to object-composit...@googlegroups.com.

[James O Coplien]

If you're trying to make a point here, I don't understand it. Can someone recap what point we're discussing and why it's important?

[Matthew Browne]

On 7/27/13 8:00 AM, James O Coplien wrote:
> If you're trying to make a point here, I don't understand it. Can
> someone recap what point we're discussing and why it's important?

I've dropped my original point because now I'm just not confused as to
what you, Mircea are others are saying.

If there's some rule in DCI that says you're not supposed to use the
same name for roles in different contexts, I've never heard of it. If
there is such a rule, I think it would be important to know about it,
and to understand the rationale for it. Mircea's last post sounded like
he said there was such a rule (or should be), but then again, maybe he
was just talking about conversing about roles rather than what you
actually name them in the code.

So that's really what I'd like to clear up. I won't bring up my other
point (about some roles being "conceptually similar") again, because
that's more subjective and isn't necessary to understand DCI (and
because I was complimenting DCI in its current form, not saying it
should be changed).

[James O Coplien]

On Jul 27, 2013, at 2:29 , Matthew Browne wrote:

> If there's some rule in DCI that says you're not supposed to use the same name for roles in different contexts, I've never heard of it.

Me, neither. But why is that pertinent to the original topic of the thread?

[Matthew Browne]

Thank you, that answers my question.

> But why is that pertinent to the original topic of the thread?

It's not, but we've often had separate discussions that deviate from the
original topic of the thread. If that's a problem, it certainly doesn't
seem that anyone in this group is acting as if it is. To me it's only a
problem if the discussion is irrelevant, nonconstructive, or deviates
from DCI. That's why I'm dropping the "similarity" point.

[Matthew Browne]

On 7/27/13 8:52 AM, Matthew Browne wrote:
> Thank you, that answers my question.
>> But why is that pertinent to the original topic of the thread?
> It's not, but we've often had separate discussions that deviate from
> the original topic of the thread. If that's a problem, it certainly
> doesn't seem that anyone in this group is acting as if it is. To me
> it's only a problem if the discussion is irrelevant, nonconstructive,
> or deviates from DCI. That's why I'm dropping the "similarity" point.

(Originally I thought it would be constructive, but the responses have
made me realize I was mistaken.)

[Trygve Reenskaug]

On 2013.07.27 14:29, Matthew Browne wrote:
> On 7/27/13 8:00 AM, James O Coplien wrote:
>
> If there's some rule in DCI that says you're not supposed to use the
> same name for roles in different contexts, I've never heard of it. If
> there is such a rule, I think it would be important to know about it,
> and to understand the rationale for it. Mircea's last post sounded
> like he said there was such a rule (or should be), but then again,
> maybe he was just talking about conversing about roles rather than
> what you actually name them in the code.

There's no such rule. Role names should be derived from the end user's
vocabulary whenever that is appropriate. If the user speaks about 'chef'
in two different contexts, so be it.

[Mircea]

I wasn't saying what you did was wrong. It's just that James's approach is one way and yours the other.

Like Trygve said, whatever is in your head is the correct way. This is what DCI is supposed to capture, so they can be either way.

PS. In your example it's true that the same person plays both roles each in it's context, but the roles are actually different (what he actually stirs or bakes can't be achieved with the same actions).

[James O Coplien]

On Jul 26, 2013, at 6:29 , Matthew Browne wrote:

I think you're right about the pattern of conversion between me and Cope. 

I'm fine with it as long as other people find it useful. Write to me privately if you feel we can be steering this in a direction more useful to everyone. In the mean time I presume the discussion is clarifying and is useful to many.

[Matthew Browne]

Yes, I remember you saying that you didn't think I was wrong, I just wanted to make sure I understood you. Thanks...I think Trygve said it best.