Re: Naming conventions

[rune funch]

Hi Trygve,

As you probably have anticipated I'm going to challenge your statement, since this is in essence our unfinished discussion From Oslo earlier this year that ended in a talk of (D)CI.

I am therefor also answering on DCI-Evolution rather than object-composition

1) Why do you think it's important where objects are stored? Does it change the semantics of my program where I store different objects? If so what makes the stack and heap so different from each other while memory and disk storage remain the same? After all we haven't discussed whether the heap is stored in RAM, stored in RAM and swapped to disk or written to disk immediately. We don't need the stack at all we could implemented it by using the heap only. This is a view that's not my own. Eric Lippert has a blog series on the same topic.

2) Why do you believe that the lifetime of an object affects how the object can be implemented? Jim Gay and I stated that any object could be implemented as a context. Neither of us mentioned the lifetime of the object. I haven't been aware of the lifetime of the Context being constraint and would find it interesting to be educated it what values brought this constraint about.

I'd also like to challenge the lifetime constraint

In Marvin contexts are immutable when it comes to RolePlayers. When the context is created the RolePlayers are bound. Binding other objects would require creating a new context. 

Let's say we have two accounts one with account number 313 and one with the number 42. 

And the execution is as follows:

we want to transfer money from 313 to 42 (MoneyTransferContext)

we wish to change the display name of 313 (ChangeAccountNameContext)

we want to transfer more money from 313 to 42 (MoneyTransferContext)

In the stack based solution we're creating three contexts and for the sack of the argument let's say that the two MoneyTransferContexts are allocated the same memory slot.

How is that program semantically different from the heap based where I Create two contexts? 

The .NET platform (and Java alike) have a stack based execution model and as such there's only ever going to be one current context and that context is going to be on the stack when the interactions are executed. The interactions are thus executed in the namespace of the top context.

In the stack based example, if I compare the two MoneyTransferContext to each other they are going to be identical in every single aspect. The RolePlayers have the same identity. The location of the context is the same and every other conceivable aspect of the two are the same.

In the heap based version it _is_ the same but is that really a semantic difference between the two programs?

Even more so comparing the stack based MoneyTransferContext to the heap based MoneyTransferContext would yield no differences what so ever either. They too might even be allocated on the same address. (of course at different times).

As a counter example to the stack based approach I put forth the task of modelling a chaotic system such as a weather system. In it's simplest form you have three interdependent systems (it's the Lorenz water wheel again). If we look at each system they are perfect for modelling as a context. When modelling each of the systems we will have to model them based on the other two systems. Each of the three systems depend on the other two and each of the three systems influence the other two systems.

(For those that are unfamiliar with the water wheel here's a short description see below)

If we want to seggregate what the system does from what it is we will have to model each system as part of what the overall system does.

The water wheel Accelerates
The bukects fill

The buckets empties

The system is

A tap

Water

A whell

X buckets

In DCI we represent what the sytem does using contexts. That could lead to

WheelAccelerationContext

BucketFillContext

BucketEmptingContext

Each context above uses both of the remaining contexts as RolePlayers but only the top context can reference to the other two contexts if it's stack based. So how would we model that? representing the other two systems as something the overall system _is_? which would go against that it is actually something the system does or would we model it so that only one of the systems are said to be active at any given time? which would go against the reality of the system and result in an ever increasing stack depth eventhough the system we model is repetitive and keeps coming back to states we've already visited before ("Lower in the stack")

Best regards
Rune

A short description of the water wheel.

The water wheel is a simplified model of several chaotic systems. It's is impossible to predict the speed of the wheel at any given time or even the direction it turns. If we had infinitely precise measurements and error free calculation it would be possible. The model is so simple that it can easily be expressed in math but even the sligthest miscalculation or error in measuring starting conditions will result in errors in our predictions. (By sligthest you should read any deviation what so ever). It's a simplification of one of the models used to predict the weather (sp now you know why they are never right), it's also a model of how water moves in a pot on a hot stove and can potentially explain why the magnetic poles switch in unpredictable manners. 

The three systems are

A tap of running water

A free spinning wheel

A set of buckets all with a hole the same size in the bottom

The speed with which the wheel turns is the integral of the accelleration of the wheel. The accelleration at any given time is dependent upon the amount of water on the left of the axis in relation to that to the right of the axis. (water going down accelerates the wheel water on the way up breaks the wheel)
The amount of water in any given bucket is a result of how long it was has been under  the running tap the (which is a function of the speed of the wheel at the time the bucket passed the tap) and how much water ran out through the hole in the bottom which is a function of the size of the hole

 

2012/5/11 Trygve Reenskaug <try...@ifi.uio.no>

Hi Rune,
Any object can clearly not be implemented as a context because objects and contexts have different lifetimes. The short story is that while a regular object lives on the heap and has an indefinite lifetime, the DCI Context lives on the stack and only exists for the duration of a system operation. The two ideas are not interchangeable. For pure behavior: yes. For handling state: no.

DCI goes back to the roots of the Simula objects. Simula has evolved into class oriented programming. DCI has added the Context, a new stack discipline that gives better control with object interaction. The Simula roots were well described by Andrew P. Black in his talk "Object-oriented programming: challenges for the next fifty years" at the University of Oslo on 25 Aug. 2011. The talk is well worth pursuing. Google the title to find it. I'll use a few quotes as a background:

“In ALGOL 60, the rules of the language have been carefully
designed to ensure that the lifetimes of block instances are
nested, in the sense that those instances that are latest
activated are the first to go out of existence. It is this feature
that permits an ALGOL 60 implementation to take advantage
of a stack as a method of dynamic storage allocation and
relinquishment. But it has the disadvantage that a program
which creates a new block instance can never interact with it
as an object which exists and has attributes, since it has
disappeared by the time the calling program regains control.
Thus the calling program can observe only the results of the
actions of the procedures it calls. Consequently, the
operational aspects of a block are overemphasised; and
algorithms (for example, matrix multiplication) are the only
concepts that can be modelled.” [Dahl1972]"
---
"Two simple changes:
“In SIMULA 67, a block instance is permitted
to outlive its calling statement, and to remain
in existence for as long as the program needs
to refer to it.” [Dahl1972]
A way of referring to “it”: object references as
data."
---
Dahl was inspired by
visualizing the runtime
representation of an Algol 60
program:
Objects were already in
existence inside every
executing Algol program —
they just needed to be freed
from the “stack discipline”

DCI is different from all this:

• Data, what the system IS, regular objects à la Simula, freed from the "stack discipline".
• Context: A special block instance that creates a namespace for blocks above it on the stack. Contexts are nested, in the sense that those instances that are latest activated are the first to go out of existence. 
• Interaction: A procedure-like execution of Role Methods within the namespace defined by the top context..

Any object can clearly not be implemented as a context because they have different lifetimes.

Cheers
--Trygve

On 2012.05.11 07:23, rune funch wrote:

Any object regardless of it's behaviour/interface can be implemented
as a context. Whether or not that it is will not be visible from the
outside.

-Rune
  

--

Trygve Reenskaug       mailto: try...@ifi.uio.no

Morgedalsvn. 5A         http://folk.uio.no/trygver/

N-0378 Oslo               Tel: (+47) 22 49 57 27

Norway

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To post to this group, send email to object-co...@googlegroups.com.
To unsubscribe from this group, send email to object-composit...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.

[Trygve Reenskaug]

Comments inline below.

On 2012.05.11 12:35, rune funch wrote:

Hi Trygve,

As you probably have anticipated I'm going to challenge your statement, since this is in essence our unfinished discussion From Oslo earlier this year that ended in a talk of (D)CI.

I am therefor also answering on DCI-Evolution rather than object-composition

As you say, we have an unfinished discussion from Oslo earlier this year. I wrote to the Composition list, hoping to make you refrain from confusing the DCI newbies by pushing your new ideas on its defenseless participants. I hope I have succeeded. The list is for explaining DCI as it is today. I believe your new ideas are can easily confuse people struggling to understand the DCI fundamentals.

1) Why do you think it's important where objects are stored? Does it change the semantics of my program where I store different objects? If so what makes the stack and heap so different from each other while memory and disk storage remain the same? After all we haven't discussed whether the heap is stored in RAM, stored in RAM and swapped to disk or written to disk immediately. We don't need the stack at all we could implemented it by using the heap only. This is a view that's not my own. Eric Lippert has a blog series on the same topic.

I use the words as abbreviations of the concepts cited by Black. Items on the stack exist from the start of an operation to its termination. Items on the heap exist exist as long as they are referenced from somewhere.

2) Why do you believe that the lifetime of an object affects how the object can be implemented? Jim Gay and I stated that any object could be implemented as a context. Neither of us mentioned the lifetime of the object. I haven't been aware of the lifetime of the Context being constraint and would find it interesting to be educated it what values brought this constraint about.

Quite simply because lifetime considerations are essential to the difference between Algol blocks and Simula objects as cited by Black. You seem to be challenging these fundamental notions, and I need more considered documentation to change the foundation of my mental models.

In DCI, there are two modes of execution. Regular POJO execution and DCI Interaction execution. The execution of a system operation in a context object goes through a crucial operation that changes the mode from POJO to Interaction. You could call it the operation that triggers the Interaction. (My current implementaton uses self triggerInteractionFrom: #Rolename with: #animateShapes andArgs: {}.).Being a POJO, a Context can do many different things in addition to triggering an Interaction. DCI is about code readability and simple mental models for end users and programmers. To me, this means that Contexts should select roleplayers and trigger interactions. Nothing more. I regard it as a flaw in my Squeak implementation that permits me adding other responsibilities to Contexts, thus obfuscating the code.

May be you are exploiting the POJO aspects of context objects and keep references to them from different parts of your program?

I'd also like to challenge the lifetime constraint

In Marvin contexts are immutable when it comes to RolePlayers. When the context is created the RolePlayers are bound. Binding other objects would require creating a new context.

Let's say we have two accounts one with account number 313 and one with the number 42.�

And the execution is as follows:

we want to transfer money from 313 to 42 (MoneyTransferContext)

we wish to change the display name of 313 (ChangeAccountNameContext)

we want to transfer more money from 313 to 42�(MoneyTransferContext)

In the stack based solution we're creating three contexts and for the sack of the argument let's say that the two MoneyTransferContexts are allocated the same memory slot.

How is that program semantically different from the heap based where I Create two contexts?

The difference between an Algol block and a Simula object, see my Black quotation. There is only one active block at the time, it only exists during the execution of an operation, and it disappears at the termination of that operation. DCI is more restricted than Algol: There is only one visible context at the time. I suggest you have to study (and document) your ideas at this level.

I won't discuss the rest of your mail because it all rests on a shared understanding of blocks, objects, and lifetimes. We aren't there yet. May be you could revise the execution model document?

The .NET platform (and Java alike) have a stack based execution model and as such there's only ever going to be one current context and that context is going to be on the stack when the interactions are executed. The interactions are thus executed in the namespace of the top context.

In the stack based example, if I compare the two MoneyTransferContext to each other they are going to be identical in every single aspect. The RolePlayers have the same identity. The location of the context is the same and every other conceivable aspect of the two are the same.

In the heap based version it _is_ the same but is that really a semantic difference between the two programs?

Even more so comparing the stack based MoneyTransferContext to the heap based MoneyTransferContext would yield no differences what so ever either. They too might even be allocated on the same address. (of course at different times).

As a counter example to the stack based approach I put forth the task of modelling a chaotic system such as a weather system. In it's simplest form you have three interdependent systems (it's the Lorenz water wheel again). If we look at each system they are perfect for modelling as a context. When modelling each of the systems we will have to model them based on the other two systems. Each of the three systems depend on the other two and each of the three systems influence the other two systems.

(For those that are unfamiliar with the water wheel here's a short description see below)

If we want to seggregate what the system does from what it is we will have to model each system as part of what the overall system does.

The water wheel Accelerates
The bukects fill

The buckets empties

The system is

A tap

Water

A whell

X buckets

In DCI we represent what the sytem does using contexts. That could lead to

WheelAccelerationContext

BucketFillContext

BucketEmptingContext

Each context above uses both of the remaining contexts as RolePlayers but only the top context can reference to the other two contexts if it's stack based. So how would we model that? representing the other two systems as something the overall system _is_? which would go against that it is actually something the system does or would we model it so that only one of the systems are said to be active at any given time? which would go against the reality of the system and result in an ever increasing stack depth eventhough the system we model is repetitive and keeps coming back to states we've already visited before ("Lower in the stack")

Best regards
Rune

A short description of the water wheel.

The water wheel is a simplified model of several chaotic systems. It's is impossible to predict the speed of the wheel at any given time or even the direction it turns. If we had infinitely precise measurements and error free calculation it would be possible. The model is so simple that it can easily be expressed in math but even the sligthest miscalculation or error in measuring starting conditions will result in errors in our predictions. (By sligthest you should read any deviation what so ever). It's a simplification of one of the models used to predict the weather (sp now you know why they are never right), it's also a model of how water moves in a pot on a hot stove and can potentially explain why the magnetic poles switch in unpredictable manners.�

The three systems are

A tap of running water

A free spinning wheel

A set of buckets all with a hole the same size in the bottom

The speed with which the wheel turns is the integral of the accelleration of the wheel. The accelleration at any given time is dependent upon the amount of water on the left of the axis in relation to that to the right of the axis. (water going down accelerates the wheel water on the way up breaks the wheel)

The amount of water in any given bucket is a result of how long it was has been under �the running tap the (which is a function of the speed of the wheel at the time the bucket passed the tap) and how much water ran out through the hole in the bottom which is a function of the size of the hole

�

2012/5/11 Trygve Reenskaug <try...@ifi.uio.no>

Hi Rune,
Any object can clearly not be implemented as a context because objects and contexts have different lifetimes. The short story is that while a regular object lives on the heap and has an indefinite lifetime, the DCI Context lives on the stack and only exists for the duration of a system operation. The two ideas are not interchangeable. For pure behavior: yes. For handling state: no.

DCI goes back to the roots of the Simula objects. Simula has evolved into class oriented programming. DCI has added the Context, a new stack discipline that gives better control with object interaction. The Simula roots were well described by Andrew P. Black in his talk "Object-oriented programming: challenges for the next fifty years" at the University of Oslo on 25 Aug. 2011. The talk is well worth pursuing. Google the title to find it. I'll use a few quotes as a background:

�In ALGOL 60, the rules of the language have been carefully

designed to ensure that the lifetimes of block instances are
nested, in the sense that those instances that are latest
activated are the first to go out of existence. It is this feature
that permits an ALGOL 60 implementation to take advantage
of a stack as a method of dynamic storage allocation and
relinquishment. But it has the disadvantage that a program
which creates a new block instance can never interact with it
as an object which exists and has attributes, since it has
disappeared by the time the calling program regains control.
Thus the calling program can observe only the results of the
actions of the procedures it calls. Consequently, the
operational aspects of a block are overemphasised; and
algorithms (for example, matrix multiplication) are the only

concepts that can be modelled.� [Dahl1972]"
---
"Two simple changes:
�In SIMULA 67, a block instance is permitted

to outlive its calling statement, and to remain
in existence for as long as the program needs

to refer to it.� [Dahl1972]
A way of referring to �it�: object references as

data."
---
Dahl was inspired by
visualizing the runtime
representation of an Algol 60
program:
Objects were already in
existence inside every

executing Algol program �

they just needed to be freed

from the �stack discipline�

DCI is different from all this:

• Data, what the system IS, regular objects � la Simula, freed from the "stack discipline".
• Context: A special block instance that creates a namespace for blocks above it on the stack. Contexts are nested, in the sense that those instances that are latest activated are the first to go out of existence.�

• Interaction: A procedure-like execution of Role Methods within the namespace defined by the top context..

Any object can clearly not be implemented as a context because they have different lifetimes.

Cheers
--Trygve

On 2012.05.11 07:23, rune funch wrote:

Any object regardless of it's behaviour/interface can be implemented
as a context. Whether or not that it is will not be visible from the
outside.

-Rune
      

Trygve Reenskaug������ mailto: try...@ifi.uio.no

Morgedalsvn. 5A ������� http://folk.uio.no/trygver/

N-0378 Oslo�������������� Tel: (+47) 22 49 57 27

Norway