Contexts are Roles when you look at them from outside, and Roles are Contexts when you look at them from inside?

[Oleh Novosad]

What bothered me is that both roles and contexts are code. I couldn't fully wrap my mind around these concepts, something felt too asymmetrical :) but I think, I finally figured it out unless I am wrong:

Contexts are actually Roles but Roles when you look at them from outside. 

Roles are Contexts but when you look at them from inside.

This means that, for example, in MVC, M, V, C - are both roles from outside and contexts from inside. For example, many black boxes (objects) can play the role of Controller, but inside of this role, Controller is actually Context that has a script for Models and Views roles.

I think maybe this is how DCI can work in a fractal way - Contexts are Roles for higher level Contexts which are Roles for higher level Contexts etc.

[James O Coplien]

Contexts can play Roles. Contexts are not Roles.

--
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 https://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

[Rune Funch Søltoft]

A context is an object a role is not. An object can play a role (if it can fulfil the role contract). Such an object is called a roleplayer. It’s not uncommon for a context to play a role (at least not in my code)

Mvh

Rune

[Oleh Novosad]

I am not sure Contexts are necessary objects/instances - this is just how it was chosen to implement contexts in specific languages. Context is just a script or set of scripts (use-cases) where instances play roles.

But what is Role? Role is also a set of scripts for an instance to play. But because instance/object is a collection of other instances/objects and because Role is supposed to use other Roles in its' implementation from inside Role is Context.

Example:

Dancer is a role that can be played by human instances in Theatre.

Dancer role has scripts that use Hand role, Leg role, Torse role, Head role etc. to do moves.

Theatre is a Context inside of which Dancers dance. 

Theatre context has play_show() method in which human instances play Dancer roles and dance.

City is a context where building instances play their roles.

Theatre is also a role for building instance. Some building instances play Theatre role, some are not.

City is a role for instances of big groups of buildings. Instances of big groups of buildings can play different roles: like City and Village.

Country is a context .....etc.

[Rune Funch Søltoft]

Den 26. feb. 2019 kl. 18.11 skrev Oleh Novosad <oleh.n...@gmail.com>:

I am not sure Contexts are necessary objects/instances

I am. From Trygve and Cope’s definition of a context found at fulloo.info

Code in the Context perspective specifies runtime networks of interconnected objects

(Emphasis mine)

[Oleh Novosad]

Code in the Context perspective specifies runtime networks of interconnected objects

(Emphasis mine)

"Runtime networks of interconnected objects" happen when the script is executed. 

It doesn't contradict with what I am saying because if Context is Role in higher level Context, in order to be executed it has to be assigned to an instance.

It is a bit hard to explain, but it doesn't contradict with what I am saying.

[rune funch]

I don't understand. You said: "I am not sure Contexts are necessary objects/instances - this is just how it was chosen to implement contexts in specific languages" and I simply replied that by definition contexts are objects and a context can't be a role but it can be a roleplayer in a higher level context

--

[Matthew Browne]

Oleh, perhaps you could share some code to demonstrate your concept? I find that when writing DCI code in practice, it becomes pretty clear how Contexts are objects that may or may not play roles in other Contexts.

For example, many black boxes (objects) can play the role of Controller, but inside of this role, Controller is actually Context that has a script for Models and Views roles.

I think you are on to something with this part. The whole purpose of the Controller is to facilitate interaction between the Model and the Views, so I agree that Controllers should (or at least could) be Contexts.

--

[Oleh Novosad]

I don't understand. You said: "I am not sure Contexts are necessary objects/instances - this is just how it was chosen to implement contexts in specific languages" and I simply replied that by definition contexts are objects and a context can't be a role but it can be a roleplayer in a higher level context

 "can be a roleplayer in a higher level context"

Yes, this is what I mean when I say that "context is role when looking from outside".

[Rune Funch Søltoft]

> Den 26. feb. 2019 kl. 19.50 skrev Oleh Novosad <oleh.n...@gmail.com>:
>
> Yes, this is what I mean when I say that "context is role when looking from outside".

To avoid confusion I would advice to using standard terminology. A role is played by a roleplayer. A context can be a roleplayer but not a role

[Oleh Novosad]

To avoid confusion I would advice to using standard terminology. A role is played by a roleplayer. A context can be a roleplayer but not a role

Are you saying that I cannot assign Theatre role to other buildings?

[Matthew Browne]

I wonder if part of the confusion here is due to not distinguishing between a Context declaration and a Context instance? e.g. for the Context declaration 'Dog' ('context Dog {...}'), there might be Context instances 'fido', 'fluffy', 'clifford', etc.

In traditional OOP we would differentiate between the "Dog class" and "Dog instances". In DCI I feel like we don't currently have the best terminology for this, and we use the same term 'context' in both ways.

Having said that, the distinction between role and role player is probably the most relevant thing here.

[Rune Funch Søltoft]

> Den 26. feb. 2019 kl. 20.03 skrev Oleh Novosad <oleh.n...@gmail.com>:
>
> Are you saying that I cannot assign Theatre role to other buildings?

No I’m saying it difficult to understand what you are trying to say. If you don’t use the common terminology. Eg you assign an object to play a role. That makes said object a roleplayer.
A role is not an object.

[James O Coplien]

I can see your perspective.

[James O Coplien]

On 26 Feb 2019, at 19.50, Oleh Novosad <oleh.n...@gmail.com> wrote:

 "can be a roleplayer in a higher level context"

Yes, this is what I mean when I say that "context is role when looking from outside".

“Can be” and “is” are not the same. As I said at the beginning: a Context instance can be a Role-player. But not all Context instances are Role-players.

[James O Coplien]

On 26 Feb 2019, at 20.03, Oleh Novosad <oleh.n...@gmail.com> wrote:

Are you saying that I cannot assign Theatre role to other buildings?

Try restating this more precisely. “Assign” is not DCI-ese.

[Oleh Novosad]

Try restating this more precisely. “Assign” is not DCI-ese.

"Are you saying that other buildings cannot play Theatre role?" 

Is this more correct?

[Oleh Novosad]

I think, my point is that Theatre is Context for humans/instances to play Dancer role.

But at the same time Theatre is Role for buildings to play Theatre.

[Rune Funch Søltoft]

I would argue that the context isn’t the Theater building but that there’s a play-context that has several roles and that play-context plays a play role in the Theater context where “my house” (or another more suitable building) plays the role of venue

Mvh

Rune

Den 26. feb. 2019 kl. 22.52 skrev Oleh Novosad <oleh.n...@gmail.com>:

I think, my point is that Theatre is Context for humans/instances to play Dancer role.

But at the same time Theatre is Role for buildings to play Theatre.

--

[Oleh Novosad]

I would argue that the context isn’t the Theater building but that there’s a play-context that has several roles and that play-context plays a play role in the Theater context where “my house” (or another more suitable building) plays the role of venue

Is there a way I can help you to understand what I am trying to say?

[James O Coplien]

On 27 Feb 2019, at 00.06, Oleh Novosad <oleh.n...@gmail.com> wrote:

Is there a way I can help you to understand what I am trying to say?

Example code. I think someone else already made this suggestion, too.

[Trygve Reenskaug]

On 27.02.2019 00:06, Oleh Novosad wrote:

I would argue that the context isn’t the Theater building but that there’s a play-context that has several roles and that play-context plays a play role in the Theater context where “my house” (or another more suitable building) plays the role of venue

Is there a way I can help you to understand what I am trying to say?

Hi Oleh,
not having followed this thread, I can only take your words on their face value. You asked for it and here is my brutal advice:
    Express your thoughts using well-defined words in a clear syntax.
Note that I do not say anything about the quality of your thoughts, not even about your ability to express them.  I only criticize the way you have expressed them in the above quote.

I see four dozen fuzzy words with arbitrary capitalization, no punctuation and not even a single line shift. I have spent a good deal of effort and good-will trying to decode them. I have used my understanding of DCI, COPE's syntax for his trygve language, and my own convention of writing role names in all caps to create my interpretation. It may or may not be what you intended:

context PlayContext {
    role CLAUDIUS {} // played by a human actor
    role HAMLET {} // played by a human actor
     ...
    }
context TheatreContext {
    role VENUE {} // played by some building such as "my house"
    role PERFORMANCE {} // played by an instance of PlayContext
    ...
    }

the point seems to be that a Context can play a role in another Context.

Enjoy
--Trygve

 

[Oleh Novosad]

I would argue that the context isn’t the Theater building but that there’s a play-context that has several roles and that play-context plays a play role in the Theater context where “my house” (or another more suitable building) plays the role of venue

Trygve, thank you, above text is not mine, Rune is trying to confuse everyone? :). 

This example is in pseudo-DCI-language

Symbol '#' marks the start of a comment.

##############################################################################

# This example shows pretty normal way of doint things

# Role definition

role DANCER 

# dance method

def dance()

#...

end 

end 

context Theater 

# play show in theatre 

def play_show(dancer as DANCER)

dancer.dance()

end 

end 

# Create human instance/object

bob = Human.new 

# Create Theatre instance, check if bob can play DANCER role and pass it to play_show() script, 
# execute play_show() script

Theather.new.play_show(bob as DANCER)

##############################################################################

# This example shows how context could be not an object, 

# everything else is pretty standard 

# Role definition

role DANCER 

# dance method

def dance()

#...

end 

end 

context Theater 

# static/class method of Theather context

def self.play_show(dancer as DANCER)

dancer.dance()

end 

end 

# create human instance

bob = Human.new 

# here we call static/class method of Theatre

Theather.play_show(bob as DANCER)

##############################################################################

# This example shows how previously Theatre context could be transformed into role

# Role definition

role DANCER 

# dance method

def dance()

#...

end 

end 

role THEATHER 

# play show in theatre 

def play_show(dancer as DANCER)

dancer.dance()

end 

end 

# create human instance

bob = Human.new 

# create building instance

building = Building.new

(building as THEATHER).play_show(bob as DANCER)

##############################################################################

# Same as above but dancer being "inside" of building

# Role definition

role DANCER 

# dance method

def dance()

#...

end 

end 

role THEATHER 

dancer as DANCER 

# play show in theatre 

def play_show()

dancer.dance()

end 

end 

# create human instance

bob = Human.new 

# create building instance

building = Building.new(dancer: bob)

# budiling plays theatre role and execute show

(building as THEATHER).play_show()

If roles can replace contexts (or be like context)  in OOP, do we need contexts at all? 

[Trygve Reenskaug]

Good for you!

--
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 https://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

--

The essence of object orientation is that objects collaborate  to achieve a goal.
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

[Rune Funch Søltoft]

Alan Kay defines OO systems as a network of interconnected systems. The definition is recursive. Each system is an object that itself might be a network of interconnected objects. It is this view of OO that DCI can express. Each context is a node in the network of interconnected objects. Within a context the expectations and (potential) contributions of each node is expressed using roles. A role is something that lives inside a specific context and has no meaning outside of a context. This makes it different from an interface, mixin etc. 

So you might have a context with a role Theater. That can be played by a subset of all buildings. In that context your might also have a play role that can be played by a context representing the concrete play eg Hamlet or Erasmus Montanus. 

Each context would have their own network of interconnected objects such as characters and stage props. In a specific context instance all roleplayers are bound to their individual roles in one atomic operation.

[Oleh Novosad]

the point seems to be that a Context can play a role in another Context.

I think the opposite is also true, Role is Context for other Roles.

[Raoul Duke]

nietzsche said: when you gaze into the navel, the navel also gazes back into you. 

[Oleh Novosad]

On Thursday, 28 February 2019 13:24:43 UTC-5, Oleh Novosad wrote:

the point seems to be that a Context can play a role in another Context.

I think the opposite is also true, Role is Context for other Roles.

I think this actually summarizes this conversation. This is what I meant from the very beginning:

"Contexts are actually Roles but Roles when you look at them from outside. 

Roles are Contexts but when you look at them from inside."

[James Coplien]

On 28 Feb 2019, at 19.24, Oleh Novosad <oleh.n...@gmail.com> wrote:

I think the opposite is also true, Role is Context for other Roles.

No. Just no.

My own suggestion would be either to read the Lean Architecture book, or to download the trygve programming environment, read its user manual, and write some code. I think just making guesses and letting us say “yes” and “no” isn’t going to get you there.

[Oleh Novosad]

 Trygve said that "the point seems to be that a Context can play a role in another Context."

If Context can be Role it means Role is Context for what was inside of that Context. So it is just a logical conclusion that "Role is Context for other Roles".

[James O Coplien]

On 28 Feb 2019, at 19.50, Oleh Novosad <oleh.n...@gmail.com> wrote:

If Context can be Role it means Role is Context for what was inside of that Context. So it is just a logical conclusion that "Role is Context for other Roles".

This is imprecise language. We need precision here.

"If Context can be Role” No, it can’t. A Context instance may play a Role.

“Context” is ambiguous and may or may not be an instance.

“Be a Role” is much different than “play a Role.”

"it means Role is Context”

No, Role is never Context.

"for what was inside of that Context”

What do you mean by “inside of that Context”? Inside of its declaration? Contained in an instance? Declared within the lexical scope of the Context declaration?

"So it is just a logical conclusion that "Role is Context for other Roles”.

For a suitable redefinition of English I suppose you are right. But English is not working here, and I can appreciate that that might be difficult. Please use code. I appreciate your attempt with pseudo-code, but it would be much better in something that runs. Hopefully that is your goal, eventually, anyhow, so you might as well get started.

[Quang]

I think you get too much into the language debate.

In DCI:

- Every object can play a Role in a Context

- Context is an object so it can PLAY a Role in a Context (even within itself)

Your theory does not make sense:

You said: 

- a Context can play a role in another Context --> Yes

- If Context can be Role it means Role is Context for what was inside of that Context --> does not make sense here

To PLAY is not TO BE

- So there is not such thing Context is Role and Role is Context.... --> this just has gone too far in the land of language mystery :)

Keep it really simple, inject a Context as an object in another Context as a Role and add Role methods into it as needed then move on.

/quang

[Oleh Novosad]

On Thursday, 28 February 2019 14:38:15 UTC-5, Quang wrote:

I think you get too much into the language debate.

In DCI:

- Every object can play a Role in a Context

- Context is an object so it can PLAY a Role in a Context (even within itself)

Your theory does not make sense:

You said: 

- a Context can play a role in another Context --> Yes

- If Context can be Role it means Role is Context for what was inside of that Context --> does not make sense here

To PLAY is not TO BE

- So there is not such thing Context is Role and Role is Context.... --> this just has gone too far in the land of language mystery :)

OK, we have "Context" and "Context instance". Context instance is an object (data in memory), so yes it can play Role. I agree.

But Context (not Context instance) is just a code, and Role is just a code. 

And yes I am saying that Context is Role from outside and Role is Context from inside.

And showed it my example where Theatre Context can be easily rewritten as Theatre Role and that Role can be applied to Building object/instance and everything works.

 

[Oleh Novosad]

Cope wrote:

Contexts can play Roles. Contexts are not Roles.

If language was not precise, I think it was not precise from both sides. Above Cope probably meant "Context instances can play Roles" instead of  "Contexts can play Roles."

[Oleh Novosad]

 

Maybe I can rephrase my point this way:

Can I inject Context (not Context instance) into some object/instance in the same we do it with Roles? If not, why?

[Rune Funch Søltoft]

> Den 28. feb. 2019 kl. 20.47 skrev Oleh Novosad <oleh.n...@gmail.com>:
>
> And showed it my example where Theatre Context can be easily rewritten as Theatre Role and that Role can be applied to Building object/instance and everything works.

And I comment in my answer several different reason why your pseudo code wasn’t DCI. The most important being that you treat roles as something independent of its enclosing context. Your code violates the mental model of both DCI and OO and hence doesn’t work as an argument for what can or can’t be done in either OO or DCI. I join the club suggesting that you try and explain your thoughts through executable code. Preferably in trygve

[Rune Funch Søltoft]

Den 28. feb. 2019 kl. 21.21 skrev Oleh Novosad <oleh.n...@gmail.com>:

 

Maybe I can rephrase my point this way:

Can I inject Context (not Context instance) into some object/instance in the same we do it with Roles? If not, why?

We can’t inject roles into some object/instance. A role is part of a context and an object can be bound to play that role. When the binding happens the role methods become part of the roleplayer. If we differentiate between a context and a context instance, then a context is a compile type construct which can’t be injected into anything.

[Oleh Novosad]

A role is part of a context and an object can be bound to play that role. When the binding happens the role methods become part of the roleplayer. If we differentiate between a context and a context instance, then a context is a compile type construct which can’t be injected into anything.

You can use the term "bind" instead of "inject" if you prefer.

Role is also compile type construct. 

Roles can be shared between contexts (I can be a Dancer not only in Theatre but also in Bar). So role can be defined outside of specific context. (This topic was discussed before).

[Trygve Reenskaug]

A Context is represented by an object. A role is NOT an object but merely a pointer to an object. So a Role can't be a  Context.

    "Role is Context for other Roles"

is the same as saying
    "a pointer is an Object for other pointers"
???

--
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 https://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

[James O Coplien]

On 28 Feb 2019, at 21.39, Oleh Novosad <oleh.n...@gmail.com> wrote:

Roles can be shared between contexts (I can be a Dancer not only in Theatre but also in Bar)

No.

In the Context “Take Order” we find the Role Waiter, with its responsibilities related to what people want to eat.

In the Context “Serve Food” we find the Role Waiter, with its responsibilities related to putting food on the table.

This is my last response. You are making ungrounded statements you believe to be true, without them being true. You can come to understand after asking a million such questions.

Please write, compile, and run some code. Until then, you are wasting our time.

[Oleh Novosad]

No.

In the Context “Take Order” we find the Role Waiter, with its responsibilities related to what people want to eat.

In the Context “Serve Food” we find the Role Waiter, with its responsibilities related to putting food on the table.

But if a person instance wants to do the same dance in Theatre context and in Bar contetx. I am sure can write executable Ruby code as I did before but it will not help you I think.

[Rune Funch Søltoft]

> Den 28. feb. 2019 kl. 21.39 skrev Oleh Novosad <oleh.n...@gmail.com>:
>
> You can use the term "bind" instead of "inject" if you prefer.

I can also use Giraf when I’m referring to an Elephant however sticking to the agreed meaning of words is often advantageous.

> Role is also compile type construct.
> Roles can be shared between contexts (I can be a Dancer not only in Theatre but also in Bar). So role can be defined outside of specific context. (This topic was discussed before).

Yes it has been discussed numerous times on this list and the conclusion is always the same. A role is an intrinsic part of a context and it makes no sense outside of said context.
If they were the same role you should expect similar behaviour from both the dancer and the roles the dancer is interacting with. Would you argue that constrain to hold in both of your proposed contexts?

[Oleh Novosad]

On Thursday, 28 February 2019 15:48:50 UTC-5, trygve wrote:

A Context is represented by an object. A role is NOT an object but merely a pointer to an object. So a Role can't be a  Context. 

If you are talking about execution time, why Context instance is not a pointer to object? 

[Rune Funch Søltoft]

> Den 28. feb. 2019 kl. 22.04 skrev Oleh Novosad <oleh.n...@gmail.com>:
>
> But if a person instance wants to do the same dance in Theatre context and in Bar contetx. I am sure can write executable Ruby code as I did before but it will not help you I think.

Yes so can the rest of us I’m sure. That proves that we can write code. However it won’t be DCI because the mental model of DCI makes any role an intrinsic part of its enclosing context. There are other ways of writing code such as you suggest above. They don’t prove anything in relation to DCI. Since you have now said that both Trygve and Cope have misunderstood DCI I’m rather confused about what you are trying to accomplish. Unless you show some real work. Ie compiling trygve code I can’t see how you or any of the rest of us would benefit from extending the discussion

[Trygve Reenskaug]

On 28.02.2019 21:21, Oleh Novosad wrote:

Maybe I can rephrase my point this way:

Can I inject Context (not Context instance) into some object/instance in the same we do it with Roles? If not, why?

No.

1. You can't inject a class into anything whatever inject means.
2. inject is not a DCI word.
3. What is it we do with Roles?

[Oleh Novosad]

Context (not Context instance) is code (use-cases scripts). Can I bind this code to some object/instance in the same way we do it with Roles? If not, why?

My point is that Theatre could be Context for Dancer role to dance.

And at the same time Theatre could be Role for a building instance (come buildings could be Theatres and some not).

Home is the context for human instance to play Father role.

But at the same time, apartment instance can play a Home role.

Gym is Context for Bodybuilder role.

But at the same time basement instance can play Gym role.

[Oleh Novosad]

Relax. I love and respect Trygve and Cope and you. I definitely don't agree that Roles cannot be shared though between contexts. But that's it. 

[Trygve Reenskaug]

Select your terminology.
Ruby terminology is fine for its uses, but DCI terminology is different.
Using DCI terminology, you are confusing the object that represents a person who knows how to dance
with a person who plays a DANCER role e.g. in a ballroom.

An object is a thing in  itself.
A role exists in a Context of interacting objects that are represented by Roles.
In your example, a Dancer (an object, an instance of class Dancer) plays a Role named DANCER in a Context named  Theater. The same Dancer plays another Role, also named DANCER,  in a Context named Bar. The Roles may be named the same, but they are different because they interact with different objects in different environments (Contexts).

On 28.02.2019 22:04, Oleh Novosad wrote:

But if a person instance wants to do the same dance in Theatre context and in Bar contetx. I am sure can write executable Ruby code as I did before but it will not help you I think.

and I could write it in FORTRAN or as an essay in plain English. But neither supports the DCI programming paradigm so they can't help us here. It would help if you tried Cope's trygve language. It's well documented and its terms are well defined. Even a simple example will clear much of the fog.

[Trygve Reenskaug]

On 28.02.2019 22:49, Oleh Novosad wrote:

Relax. I love and respect Trygve and Cope and you. I definitely don't agree that Roles cannot be shared though between contexts. But that's it. 

This only proves that you do not understand DCI.

[Trygve Reenskaug]

Sorry. This was sent to Oleh only, should have been sent the list.
-----------------------
Webster's dictionary defines the ordinary meaning of ordinary words.
Mathematicians and programmers define extraordinary meaning for ordinary words. (Example: tree)

In my part of the world, Cope's language is precise:
    If "Context" is is the name of a class,
    "a Context" is short for "an instance of class Context".
    "Contexts" is short for "instances of class Context".
I don't think I have ever seen this explained because it's common knowledge in the community.

You can easily be mislead if you confuse Webster's dictionary with technical terminology. See this thread for examples.

--

[Trygve Reenskaug]

Sorry. This was sent to Oleh only, should have been sent the list.
-----------------------
Webster's dictionary defines the ordinary meaning of ordinary words.
Mathematicians and programmers define extraordinary meaning for ordinary words. (Example: tree)

In my part of the world, Cope's language is precise:
    If "Context" is is the name of a class,
    "a Context" is short for "an instance of class Context".
    "Contexts" is short for "instances of class Context".
I don't think I have ever seen this explained because it's common knowledge in the community.

You can easily be mislead if you confuse Webster's dictionary with technical terminology. See this thread for examples.

On 28.02.2019 20:59, Oleh Novosad wrote:

--

[Oleh Novosad]

An object is a thing in  itself.
A role exists in a Context of interacting objects that are represented by Roles.
In your example, a Dancer (an object, an instance of class Dancer) plays a Role named DANCER in a Context named  Theater. The same Dancer plays another Role, also named DANCER,  in a Context named Bar. The Roles may be named the same, but they are different because they interact with different objects in different environments (Contexts).

What if DANCER Role code in Theatre is not different from DANCER Role code in Bar? Literary the same code to move body parts. Why cannot I share that code between Contexts?

and I could write it in FORTRAN or as an essay in plain English. But neither supports the DCI programming paradigm so they can't help us here. It would help if you tried Cope's trygve language. It's well documented and its terms are well defined. Even a simple example will clear much of the fog.

Problem with trygve language is that everything is set in stone, including how Context is defined and used. How can I show something in a language that doesn't support what I want to show.

[Oleh Novosad]

Context (not a Context instance) is code (use-cases scripts). Can I bind this code to some object/instance in the same way we do it with Roles? If not, why?

My point is that Theatre could be Context for Dancer role to dance.

And at the same time Theatre could be Role for a building instance (some buildings could be Theatres and some not).

[Matthew Browne]

Hi Oleh,
I think I understand your question better now, but I'm unclear on your underlying goal. It seems like you are suggesting a modification/extension to DCI to allow the use case logic in Contexts to be reused in a different way, but is this just academic or is it because you tried to use DCI as envisioned by Trygve and Cope and had trouble with it? Have you used DCI in a real app? Healthy skepticism of a new paradigm is a good thing, but I suggest that you take a scientific approach and treat DCI as an experiment. Remain open-minded and recognize that what you see as shortcomings might not even be shortcomings at all as you understand it better. This is not to say that DCI can't be improved in any way or that DCI is the only valid paradigm—far from it. But I think it's more than fair to expect people to demonstrate a full understanding of DCI before any debate about it can be productive. This group can help you come to that understanding, but only if you take a step back and get out of debate mode for a while.

[Matthew Browne]

On 2/28/19 5:30 PM, Oleh Novosad wrote:

Context (not a Context instance) is code (use-cases scripts). Can I bind this code to some object/instance in the same way we do it with Roles? If not, why?

Code reuse in DCI is achieved via Contexts playing roles in other Contexts. (I am using "context" to mean "context instance"—any time you hear that X is "playing a role", it's safe to assume that X is an instance, not a type or class.) Roles are not reusable (except indirectly via Contexts, of course). As others have pointed out several times, roles are intrinsic and specific to the Contexts to which they belong.

I realize this probably seems counterintuitive (it was to me at first), but in practice I have never seen a situation where the exact same code for a role in one Context actually could be reused verbatim in another Context. Cope gave a good example of a role named "Waiter" in two different Contexts. Don't be misled by the fact that it has the same name—as far as DCI is concerned, the role in one Context is completely independent from a same-named role in any other Context. If you've encountered a real-life situation in a real-life DCI app where you felt the need to reuse the same role methods verbatim in multiple Contexts, I'd be interested to see it. I strongly suspect that by examining the example together with the group, you'd find that it could be reworked in a way consistent with DCI's mental model that was more elegant or equally elegant as the alternative you've been suggesting.

Finally, it's worth noting that keeping your code DRY isn't the foremost goal of DCI; DCI's primary emphasis is on keeping your code readable. Avoiding repetition is often complimentary with the goal of readable code of course, but not always. Sometimes a small amount of repetition (might only be a few lines) is more than worth the maintenance cost and mental overhead of a much more complicated but more DRY solution.

[Matthew Browne]

Also, here's a shorter and more direct answer to your question:

> Context (not a Context instance) is code (use-cases scripts). Can I
> bind this code to some object/instance in the same way we do it with
> Roles? If not, why?

No, this is not possible in DCI. This is deliberately not a feature of DCI because it would complicate and confuse the mental model of roles for no gain. This feature is simply not necessary, since DCI already acheives the goals of readable code and code reuse without needing this. But this isn't something that can be understood with theory alone; you have to see the code. Try writing code in the DCI way and see what happens.
--
Sent from my Android device with K-9 Mail.

[Trygve Reenskaug]

 

Oleh Novosad
<oleh.novosad
@gmail.com>

My Lord,
It gives Us Great Pleasure  to Institute you with

The Most Noble Order of the Troll

You have Honorably Satisfied the Exacting Requirements of Our Order, videlicet:

• You have shown great aptitude in keeping the Ball rolling by using many words with doubtful pedigree.
• You have with great skill avoided doing any real work yourself such as writing executable code.
• You have managed to create work for your interlocutors in the form of writing textbook snippets and even executable code

Signed this 2nd Day of March in the Year MMXIV
Trygve

[Oleh Novosad]

Thank you, Mathew. I appreciate your answers.

[Matthew Browne]

This is a little harsh, Trygve. Yes, Oleh was prematurely criticizing DCI based on some mistaken assumptions. But there is nothing in the group description (or some other message sent to new members, as far as I know) that tells people that this sort of premature debate is not welcome in this group. Perhaps it should be obvious, but I don't think we should label people as trolls based on what might have just been a wrong expectation.

I got the impression that Oleh—who first posted in the group nearly a year ago, it looks like—is genuinely interested in DCI, albeit skeptical. Now that we've pointed out his mistaken assumptions, maybe he'll respond differently. Consider these quotes from Oleh:

Is there a way I can help you to understand what I am trying to say?

...

How can I show something in a language that doesn't support what I want to show.

These sound to me like a person who is struggling to communicate their concern and/or confusion, not someone who's just intending to waste everyone's time.

To Oleh: Regarding your question about showing your idea in code, before trying to demonstrate your alternative idea, I would take a realistic example and implement it using the trygve language, and show it to the group for feedback. After that, you could use any language that allows you to inject methods into objects at runtime (e.g. Ruby or JS) to show an alternative way of implementing the same example. Then we could actually have a productive discussion.

[Oleh Novosad]

I am actually not criticizing DCI. In fact, I was trying to use if not full DCI, at least mental model of it in my applications. And I was telling about DCI to all my friends/coworkers.

And I really love the idea about making the code more readable and fully support these kinds of ideas.

I am just curious about different ideas and different angles. Have I asked stupid questions? 

Basically, I just showed that Context could be rewritten as Role and asked questions about it.

My wife could understand this in 3 min, same as my coworkers. And instead of getting simple answers to simple questions I got all that nonsense.

Maybe this reaction is because someone got scary? It was not my goal though.

And use understandable language instead of cryptic something based on articles (which good languages doesn't even use):

    If "Context" is is the name of a class,
    "a Context" is short for "an instance of class Context". 
    "Contexts" is short for "instances of class Context".

And trygve language syntax is UGLY.

Being not able to share roles between contexts is stupid in my opinion.

And Rune was sending me private messages into my email box about how important he is in DCI.

[Matthew Browne]

On 3/2/19 8:47 AM, Oleh Novosad wrote:

> Being not able to share roles between contexts is stupid in my opinion.

That was uncalled for, especially after I and others just tried to
patiently explain the reasons for this. Please understand that even if
you were correct about this, any claims about how DCI should be changed
or extended are totally unhelpful to us if they are not based on a solid
foundation. And the responses you received were not "nonsense." I found
your posts to be much harder to understand than anything others said. I
doubt you would walk into a panel of experts on some other area of
programming you've only dabbled in and call something about their
approach "stupid". Please show us the same respect.

> Maybe this reaction is because someone got scary?

I don't think anyone here is the least bit scared or concerned about
appearances. DCI isn't anywhere near mainstream and we're much more
concerned with correctly communicating what DCI is about than convincing
skeptics and growing our community just for the sake of numbers. If you
want to insist that your proposed change/extension to DCI is better even
though everyone with more experience with DCI disagrees and you have yet
to make a full investment in understanding it, then go right ahead, but
it won't prove anything.

There are clearly misperceptions and miscommunications on both sides.
Let's just drop it so that things don't get ugly.

There's still an opportunity for a productive discussion here, but not
if we continue down this path.

[James O Coplien]

On 2 Mar 2019, at 14.47, Oleh Novosad <oleh.n...@gmail.com> wrote:

I was trying to use 

I’m sorry: you showed no effort of trying to use it, in spite of repeated calls for you to show code.

On 3/2/19 8:47 AM, Oleh Novosad wrote:

Being not able to share roles between contexts is stupid in my opinion.

As Matthew said, this was uncalled for.

I hope this is over. You have been amply warned. As moderator I will remove you from this group if there is as much as a single additional inappropriate post from you. I will be the judge of such appropriateness.

[Slava Ukraini]

I was going to write an example in trygve language over this weekend. But conclusions were made before I was able to do that (example in Ruby was provided).

This conversation might have gone in this way:

Oleh: How about an idea that Role and Context are actually the same? That context used in higher level context could be a role? I don't know why Context should be necessarily stateful if it is just a use-case script?

Someone: No, you are stupid. This is wrong.

Oleh: Why?

Someone: Because of this and this and this.

Oleh: Thank you.

Instead, I was called a TROLL for asking questions. I didn't ask Trygve or Cope to answer me themselves. I don't think my question should necessarily take their time.  

I was called a TROLL because I was asking not comfortable questions in my opinion.

Imagine that Role and Context could be actually the same thing but under a different angle. This could be uncomfortable, books and texts are written. I don't know if this is true but it looks like that. It is easier to shame me.

 I AM PROUD to be out of here. Fuck you, brain-dead old people.

Respect to Mathew and Quang for good answers and questions.

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

[Matthew Browne]

I'm sad that it came to this. I don't think it had to end this way. I think Oleh and Trygve both misread the situation. But obviously we can't tolerate disrespectful people and it's too late now.

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.

[Rune Funch Søltoft]

> Den 2. mar. 2019 kl. 14.47 skrev Oleh Novosad <oleh.n...@gmail.com>:
>
> And trygve language syntax is UGLY.
> Being not able to share roles between contexts is stupid in my opinion.
> And Rune was sending me private messages into my email box about how important he is in DCI

You need to stop attacking people. Especially people that was trying to help you and most of all you need to stop lying. Never did you receive a mail where I said I was important. You receive a mail where I told you what my contributions to DCI have been. As I also stated in the mail I did this because from your mails it seem as if you didn’t know, that I actually knew what I was talking about. Instead of reflecting upon my answers to you, you claimed that what I (and every one else) said was wrong. Haven seen this before on this list and knowing where we were headed (the present situation) I tried to tell you that I without a doubt were likely to have a better understanding of DCI than you. Unfortunately instead of heeding the advice you took to attacking people on the list where you could have of tried to understand their arguments.
The core misunderstanding have been about sharing roles between contexts. In my Family context we have a role called daughter. Would it make sense to share that context with your family? Of course not. Not even if we expected the same behaviour of the role players. Why wouldn’t it make sense because a role is more that the role behaviour it’s also a node in an interaction graph and the role of being my daughter has some expected behaviour AND a relation to me. The only thing that might ever be duplicated in another family context is the expected behaviour but NEVER the interaction graph

[Matthew Browne]

On 3/2/19 11:44 AM, Rune Funch Søltoft wrote:

The core misunderstanding have been about sharing roles between contexts. In my Family context we have a role called daughter. Would it make sense to share that context with your family? Of course not. Not even if we expected the same behaviour of the role players. Why wouldn’t it make sense because a role is more that the role behaviour it’s also a node in an interaction graph and the role of being my daughter has some expected behaviour AND a relation to me. The only thing that might ever be duplicated in another family context is the expected behaviour but NEVER the interaction graph

Well said, Rune. This might be falling on deaf ears at this point, but for posterity, perhaps one other thing worth adding is that in DCI there are already ways to reuse behavior shared between roles, including helper functions and shared nested contexts. So in effect (loosely speaking), parts of roles can be shared, but sharing the whole role wouldn't make sense and is incompatible with the contextual role-based model that makes DCI so effective.

[Daniel P]

On Thursday, February 28, 2019 at 4:18:31 PM UTC-5, trygve wrote:

1. You can't inject a class into anything whatever inject means.
2. inject is not a DCI word 

If I could ask a tangential question (my first question on this group!), the word "inject" appears many times in Coplien's Lean Architecture book, where he talks about using traits to "inject" algorithms ("methodful object roles") into classes ("domain classes"). In what sense then is "inject" not a DCI word? Are you suggesting that the word "inject" does not belong in a formal treatment of DCI? Could you point me to an article about DCI that you regard as normative?

Thanks!

Daniel

[Rune Funch Søltoft]

> Den 6. mar. 2019 kl. 15.45 skrev Daniel P <daniel...@gmail.com>:
>
> In what sense then is "inject" not a DCI word? Are you suggesting that the word "inject" does not belong in a formal treatment of DCI?

When the book was written “injecting” was the way objects was enriched. This method turned out to be an implementation detail and not an intricate part of the DCI mental model.
At the time the book was written at least Trygve saw injection as the only possible solution. I to some extend created Marvin to show that injection wasn’t required (trygve, the language, has later shown some issues that arose from some of my design decisions, specifically when inspecting the runtime).
Another word has been use for quite some time. Bind. Binding of objects to a role has specific meaning in DCI.

[James O Coplien]

Yup. Injection is a technique. DCI semantics are at a higher level.

Sendt fra min iPhone

[Matthew Browne]

In case it wasn't clear, "injection" in this case is short for "method injection", meaning to inject additional methods into an existing object at run-time.

[Daniel P]

Thanks for the responses, appreciated.

In Lean Architecture, Coplien uses the language "T presumes on the class into which it will be injected to support [some methods]", for object role T, a class, so my reading is that this is about "injecting" one class ("object role") into another class. I understand how this can be considered "method injection". But I feel I must be missing something given trygve's emphatically expressed assertion that "You can't inject a class into anything whatever inject means." Is this simply a difference in perspective, with trygve's interest being more in dynamically typed languages, and Coplien's extending to statically typed? Any insight appreciated. 

Best regards,

Daniel

On Wednesday, March 6, 2019 at 12:55:55 PM UTC-5, Matthew Browne wrote:

In case it wasn't clear, "injection" in this case is short for "method injection", meaning to inject additional methods into an existing object at run-time.

On Wed, Mar 6, 2019, 10:35 AM James O Coplien <jcop...@gmail.com> wrote:

Yup. Injection is a technique. DCI semantics are at a higher level.

Sendt fra min iPhone

> Den 6. mar. 2019 kl. 16.05 skrev Rune Funch Søltoft <funchs...@gmail.com>:
>
>
>> Den 6. mar. 2019 kl. 15.45 skrev Daniel P <daniel...@gmail.com>:
>>
>> In what sense then is "inject" not a DCI word? Are you suggesting that the word "inject" does not belong in a formal treatment of DCI?
> When the book was written “injecting” was the way objects was enriched. This method turned out to be an implementation detail and not an intricate part of the DCI mental model.
> At the time the book was written at least Trygve saw injection as the only possible solution. I to some extend created Marvin to show that injection wasn’t required (trygve, the language, has later shown some issues that arose from some of my design decisions, specifically when inspecting the runtime).
> Another word has been use for quite some time. Bind. Binding of objects to a role has specific meaning in DCI.
>
> --
> 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 https://groups.google.com/group/object-composition.
> For more options, visit https://groups.google.com/d/optout.

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

[Daniel P]

Thanks for your response, appreciated. Incidentally, is top posting or bottom posting the custom here? I started bottom posting, but the replies have come either way :-)

When you wrote "Trygve saw injection as the only possible solution" did you mean "Coplein saw injection as the only possible solution"? It's Coplein's book, and Trygve doesn't seem to approve of the term inject! Or is there more to the story?

Specifically in the context of C++ (my understanding of the DCI examples is limited to the ones in C++), would you say that DCI allows alternatives to method injection using templates, or are the alternatives you're referring to only meaningful in other languages?

Best regards,

Daniel

[Daniel P]

Thanks, if I could ask one more question, won't take your up time with more!

In Lean Architecture, are the terms "role class" and "traits" used synonymously, or is one considered to be more general? When these terms appear in the text, they usually appear in the joint expression "role classes or traits", and I'm hesitant to read more meaning into the word "traits" than what actually appears in the text.

Thanks,

Daniel

On Wednesday, March 6, 2019 at 10:35:38 AM UTC-5, Cope wrote:

Yup. Injection is a technique. DCI semantics are at a higher level.

Sendt fra min iPhone

> Den 6. mar. 2019 kl. 16.05 skrev Rune Funch Søltoft <funchs...@gmail.com>:
>
>
>> Den 6. mar. 2019 kl. 15.45 skrev Daniel P <daniel...@gmail.com>:
>>
>> In what sense then is "inject" not a DCI word? Are you suggesting that the word "inject" does not belong in a formal treatment of DCI?
> When the book was written “injecting” was the way objects was enriched. This method turned out to be an implementation detail and not an intricate part of the DCI mental model.
> At the time the book was written at least Trygve saw injection as the only possible solution. I to some extend created Marvin to show that injection wasn’t required (trygve, the language, has later shown some issues that arose from some of my design decisions, specifically when inspecting the runtime).
> Another word has been use for quite some time. Bind. Binding of objects to a role has specific meaning in DCI.
>
> --
> 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.

[Rune Funch Søltoft]

> Den 7. mar. 2019 kl. 01.33 skrev Daniel P <daniel...@gmail.com>:
>
> When you wrote "Trygve saw injection as the only possible solution" did you mean "Coplein saw injection as the only possible solution"? It's Coplein's book, and Trygve doesn't seem to approve of the term inject! Or is there more to the story?

No I ment Trygve who started DCI and hence the vocabulary. My point it that when you can see only one implementation technique you are likely to name the concept after that technique.

>
> Specifically in the context of C++ (my understanding of the DCI examples is limited to the ones in C++), would you say that DCI allows alternatives to method injection using templates

DCI has no saying on implementation details. DCI relates to mental models not the size of the addressing space, instruction set of the professor nor about programming languages. There are however issues with runtime injection such as when using extent in Ruby

[Trygve Reenskaug]

BabyIDE was the first implementation of the DCI programming paradigm. It used Traits to realize role methods (scripts):

https://stackoverflow.com/questions/9205083/traits-vs-interfaces:
Traits is a mechanism for code reuse in single inheritance languages such as PHP. A Trait is intended to reduce some limitations of single inheritance by enabling a developer to reuse sets of methods freely in several independent classes living in different class hierarchies.

My mental model was that Trait methods were injected into the objects. (I very rarely worry about classes). I didn't like that a class had to know the Traits that enabled its instances to play Roles in Contexts: I wanted a stronger separation of concerns  between Data and Context/Roles. My implementation was in Smalltalk and with Cope's help, a new mechanism using introspection gave me "injectionless" DCI. I have continued along this path and the "injection" went out of my vocabulary together with "Traits" many  years ago.

Cope and I have separated into two lines of research. I have programmed exclusively in Smalltalk since 1978 and use Smalltalk as my laboratory for DCI. I am writing about DCI, talking about DCI, and programming with DCI  without injection. I tend to forget that Cope's trygve language is a 3GL and I believe he is using some kind of injection in its implementation.

"injection" is not part of my DCI vocabulary but it may be part of Cope's.  I'm sorry for being responsible for the confusion.
--Trygve

[James O Coplien]

No. I use a self tuple on the stack. There is an underlying virtual machine that does method lookup. It is as dynamic as Baby IDE. Unlike Baby IDE, it is compile-time safe. 

Sendt fra min iPhone

[James O Coplien]

Traits — on which Trygve’s implementation is based — are a mechanism for class composition. In the simple understanding of the word “inject” one can view traits as a way to inject two classes into each other.

The pretense in DCI is that the method associations happen at the object level, but behind the scenes there is always some kind of association of class-like things in all the implementations I know of. There are several mental models of DCI implementation, They are all just mental crutches, since at the level of the real flip-flops of memory nothing is being injected into anything.

We make convenient models that adjacent words of the address space are physically adjacent on the same chip in memory (which, because of memory fetch efficiency designs, may not be true) and at the next higher level think of objects and classes having nesting properties (which at the level of the bits is geometrically preposterous). So we create geometries that fulfill our fantasies. Rosen (the symmetry and symmetry-breaking guy) says that these geometries are just as “real” as the physical ones: they obey all the same laws of group function closure, composition, and inverses. So whether there is “injection” or not is largely a matter of a (rather arbitrary) choice of a mental model by which to reason about the geometry of objects in the machine. All that is in the machine are data: objects are information and, as such, live only in the mind.

Finally, DCI is an application of an additional mental model on top of the virtual machine.

One of the goals of the trygve project was to formalize this mental model in terms of a formally defined virtual machine. It exists. I think it has been only tacit in most other DCI implementations. So I think arguing about injection doesn’t lend much insight into the semantics of DCI. The main DCI semantics are behavioural and are better-suited to retract theory and describing compositions of behaviours rather than the geometry of physical metaphors. In the same sense that Ungar et al. showed that delegation and inheritance are logically equivalent, I would muse that one could do a formal analysis of DCI that shows that injection and other mechanisms are equivalent as regards most important properties of a DCI implementation.

Trygve seems to disagree since he just mentioned Baby as the first implementation of DCI, whereas the first implementation that was actually able to do this class composition properly, to implement the Context / Role / Class triple, was in C++. The operational difference between the Baby implementation and the C++ traits implementation is largely in the compile-time overhead of code generation, which has never really arisen as a central salient DCI property. All the other differences are artifices of the engineering mental model one applies. For example, if one object of class C plays role R in the C++ implementation, then all objects of class C can play role R. It doesn’t mean that one must use the role methods of those objects. In C++ a wayward invocation of such a method would succeed, which is inappropriate. In Smalltalk it is much better because the program crashes with a “method not understood” message. The trygve implementation perfectly fixes both of these: it has moved on to create a practical, useful virtual machine based on a much more robust mental model than anything where we need to argue about whither injection. Other implementations are still stuck where we were almost ten years ago.

[James O Coplien]

> On 7 Mar 2019, at 10.19, James O Coplien <jcop...@gmail.com> wrote:
> Other implementations are still stuck where we were almost ten years ago.

I should add that there are also others, like some of Rune’s implementations, that also have moved us forward along this line — though I am not sure that the virtual machine has been the focus of that work. I think the focus has been more on getting the method association semantics right at the source language level. That’s where the rubber meets the road.

[Trygve Reenskaug]

On 07.03.2019 10:19, James O Coplien wrote:

Traits — on which Trygve’s implementation is based — are a mechanism for class composition. In the simple understanding of the word “inject” one can view traits as a way to inject two classes into each other.

[Trygve] As I said in my mail, it's many years since there was a relationship between Data classes and Contexts/Roles at compile time in my iplementation. I have no Traits

The pretense in DCI is that the method associations happen at the object level, but behind the scenes there is always some kind of association of class-like things in all the implementations I know of. There are several mental models of DCI implementation, They are all just mental crutches, since at the level of the real flip-flops of memory nothing is being injected into anything.

We make convenient models that adjacent words of the address space are physically adjacent on the same chip in memory (which, because of memory fetch efficiency designs, may not be true) and at the next higher level think of objects and classes having nesting properties (which at the level of the bits is geometrically preposterous). So we create geometries that fulfill our fantasies. Rosen (the symmetry and symmetry-breaking guy) says that these geometries are just as “real” as the physical ones: they obey all the same laws of group function closure, composition, and inverses. So whether there is “injection” or not is largely a matter of a (rather arbitrary) choice of a mental model by which to reason about the geometry of objects in the machine. All that is in the machine are data: objects are information and, as such, live only in the mind.

Finally, DCI is an application of an additional mental model on top of the virtual machine.

[Trygve] On top of the virtual OO machine. This is important, IMO

One of the goals of the trygve project was to formalize this mental model in terms of a formally defined virtual machine. It exists. I think it has been only tacit in most other DCI implementations. So I think arguing about injection doesn’t lend much insight into the semantics of DCI. The main DCI semantics are behavioural and are better-suited to retract theory and describing compositions of behaviours rather than the geometry of physical metaphors. In the same sense that Ungar et al. showed that delegation and inheritance are logically equivalent, I would muse that one could do a formal analysis of DCI that shows that injection and other mechanisms are equivalent as regards most important properties of a DCI implementation.

Trygve seems to disagree since he just mentioned Baby as the first implementation of DCI, whereas the first implementation that was actually able to do this class composition properly, to implement the Context / Role / Class triple, was in C++.

[Trygve] I can't see it is important to determine who went first, considering our close cooperation with DCI. (BTW, DCI and BabyIDE was first made public 28.08.2008)

The operational difference between the Baby implementation and the C++ traits implementation is largely in the compile-time overhead of code generation, which has never really arisen as a central salient DCI property.

[Trygve]There's also the difference that in BabyIDE (the personal programming version), any object can play a role. An example is a weather service accessible through the web. And of course there is the solid theoretical underpinnings of trygve that are completely lacking in BabyIDE.

All the other differences are artifices of the engineering mental model one applies. For example, if one object of class C plays role R in the C++ implementation, then all objects of class C can play role R. It doesn’t mean that one must use the role methods of those objects. In C++ a wayward invocation of such a method would succeed, which is inappropriate. In Smalltalk it is much better because the program crashes with a “method not understood” message.

[Trygve]No, Smalltalk  doesn't crash. “method not understood” is a method in class Object. The default action is to open a debugger at the point of the error. Subclasses of Object can handle "method not understood" in their own way. (Useful for creating wrappers)

The trygve implementation perfectly fixes both of these: it has moved on to create a practical, useful virtual machine based on a much more robust mental model than anything where we need to argue about whither injection.

[Trygve] How true! I would like to go deeply into the semantic model of trygve and compare it with the semantic model behind BabyIDE and see if I can remove (some of) the discrepancies.

[Rune Funch Søltoft]

> Den 7. mar. 2019 kl. 10.23 skrev James O Coplien <jcop...@gmail.com>:
>
> though I am not sure that the virtual machine has been the focus of that work.

That is correct. Marvin and maroon are comparable to trygve at compile/interpretation time but falls behind when comparing runtime. That’s is you seen the “tricks” when debugging either because the underlying VM does support the mental model

[James O Coplien]

On 7 Mar 2019, at 11.27, Trygve Reenskaug <try...@ifi.uio.no> wrote:

any object can play a role. 

I do not understand how trygve and Baby IDE differ in this regard.

[Trygve Reenskaug]

I have the impression that only instances of classes defined within the scope of the trygve program can play roles in trygve. Don't you have to create a wrapper around a web service to make it play a role?

There is now work in progress to create a global standard for uniquely identifying every object in the world regardless of what it represents and how it is reified (particularly IoT things). A popular candidate is the Universally unique identifier (UUID): which is a 128 bit number. This universe of identified objects extends into the BabyIDE image so that they can play Roles in a Context. If the object is a RESTful server, very interesting vistas opens for making personal programming (PP) simpler and more intuitive compared to programming with a 3GL. The project page is at http://folk.uio.no/trygver/themes/Personal/pp-index.html . Link to my 55 page draft article on PP is at the bottom.

[James O Coplien]

On 7 Mar 2019, at 12.20, Trygve Reenskaug <try...@ifi.uio.no> wrote:

I have the impression that only instances of classes defined within the scope of the trygve program can play roles in trygve. Don't you have to create a wrapper around a web service to make it play a role?

I think it is just a question, in general, of whether the language provides that wrapper or the programmer provides that wrapper. There is nothing in principle preventing the language from providing that wrapper. It doesn’t provide seamless interfaces to a database, either, but then neither does Baby — unless you have loaded Lens into your Smalltalk image. I see no difference.

I tried for several days to create a trygve class that would allow remote access to weather information worldwide. All web sites I found either required a subscription or had such a complex format that I would in essence have had to implement a web browser to interpret the results, and I thought that both of these stood in the way of delivering a usable prototype. I’ll bet that Baby can’t work with monetized sites unless it has implemented pretty sophisticated cookie management, either. This is a read herring.

On 7 Mar 2019, at 12.20, Trygve Reenskaug <try...@ifi.uio.no> wrote:

There is now work in progress to create a global standard for uniquely identifying every object in the world regardless of what it represents and how it is reified (particularly IoT things)

Sounds like RMODP one more time with feeling. Tower of Babel. Apollo tried it and failed. I think that URLs and the SGML standard are the half-baked solutions that will continue to fill that space.

[Matthew Browne]

On 3/7/19 2:47 AM, Trygve Reenskaug wrote:

https://stackoverflow.com/questions/9205083/traits-vs-interfaces:
Traits is a mechanism for code reuse in single inheritance languages such as PHP. A Trait is intended to reduce some limitations of single inheritance by enabling a developer to reuse sets of methods freely in several independent classes living in different class hierarchies.

This is a bit off-topic, but since this quote mentions PHP, I just wanted to point out that "traits" are implemented differently in different languages (and some languages don't really have them at all...they can usually be emulated somehow, but for implementations that do source code transformation or for a full-fledged DCI VM like trygve, traits are not needed at all).

DCI is of course object-oriented rather than class-oriented, so the trait implementations that lend themselves best to it are those that let you add traits to specific objects. Scala allows this via the 'with' keyword—example. Note: that example is doing it at instantiation time, whereas in DCI you should ideally be able to dynamically add roles to existing objects when a particular use case (Context) begins. Ruby and JavaScript, while lacking some of the dedicated traits features that Scala has, both have the ability to inject methods into an existing object, which comes in very handy for implementing DCI...although as Rune mentioned, the method injection technique still has issues, particularly when it comes to removing the role methods after a use case ends. In JavaScript you can use symbols instead of string keys to avoid the need to worry about removing role methods at all (example), thanks to the fact that symbols are guaranteed to be unique and not conflict with existing string keys (but admittedly the dichotomy this creates between role methods and regular methods is unfortunate).

Anyway, getting back to PHP, I thought it was worth mentioning that PHP does not have the same kind of flexibility when it comes to traits as any of the above languages. In PHP, you can add traits to classes at compile-time and that's it; you can't use them to directly add roles to individual objects. My DCI implementation for PHP actually does make use of traits, but not in the way you might expect. (My implementation only uses the traits as a convenient place for the programmer to write his/her role methods; at run-time it actually creates a new class that uses the trait to essentially copy over all the role methods so they can actually be called.)

[Trygve Reenskaug]

I thought you didn't like wrappers because they can lead to identity problems. And it's no surprise that you had trouble with accessing remote servers from Squeak. I believe there is a Squeak package for accessing the Net and even a network browser in Squeak. May be you tried it and it didn't work. My solution is work-in-progress.

There is ongoing work to identify the world's objects with globally unique identifiers: UUID is a 128 bit, globally unique identifier intended for identifying billions of objects across vendors, countries, languages, technologies, and protocols. In BabyIDE, I am creating a virtual and uniform universe of objects that includes both Squeak and objects and all objects identified with UUID. For the writer of a role script, a message send is a message send irrespective of the kind of receiver.  This works in BabyIDE, I'm only missing the communication parts.

I still need to buy Things for my home and to access them from BabyIDE. I expect the Things (curtains, lights, ...) will be like this window alarm: (https://www.stripsbysensative.com/). Quite amazing IMO: A magnetic door & window alarm on an adhesive tape. The tape hides magnetic sensor, processor, a Z-wave radio transceiver, and a 10-year battery. I need a box that transforms from Z-wave to Ethernet and thence to Squeak software that supports TCP/IP. Also software that can handle RESTful servers. I hope most of it exists and I am eager to understand it and connect it up. 

Unfortunately, I have to finish my article first (I'm 88).

--

[James O Coplien]

On 7 Mar 2019, at 14.47, Trygve Reenskaug <try...@ifi.uio.no> wrote:

I thought you didn't like wrappers because they can lead to identity problems.

Yes, for an object wrapping an object within some execution scope. But since you’re an OO guy, and I’m a multi-paradigm guy, I cater to folks like you by wrapping non-objects (hardware elements, database relations, stored procedures, external hardware acuators) in objects. The real world out there is not object-oriented: only our mental models are. I provide support for the mental models with wrappers. As long as you are attentive to identity it works fine. And I can interact with the real world. A wrapperless OO world cannot.

The alternative is to make an object equivalent for each of the 10,000,000 non-object things in the IoT world. I’ve worked quite a bit with such folks at Bosch (https://twitter.com/jcoplien/status/1008732351587897344). This alternative-object direction is exactly what RM/ODP tried to do — and look where they are today.

[Trygve Reenskaug]

I'm sure you are right. You usually are.
I'll burn my fingers just for the fun of it.

--
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 https://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

--

The essence of object orientation is that objects collaborate  to achieve a goal.
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

[Daniel P]

Thanks, that answers all of my questions. 

Best regards,

Daniel