Elephant Paper - Six Wise Men and the Elephant

[Matthew Browne]

Hi,
I am posting the elephant paper (written by James Coplien) here so it
will be easier to find it in the future. The paper was unfortunately
never published but according to a previous thread, this is probably the
latest draft.

It's a very enjoyable and informative read.

Cheers,
Matt

[Vlad Lyga]

Hello,

Have read it several times, great paper overall, 

though i found the elephant allegory is stretched too much in places.

But there is one thing i am not getting.

In the section about Mix-Ins there is an example of DCI roles allowing "grouping by behaviour". 

What i'm not getting is what exactly it suppose to mean?

 - Multiple role players playing same role in same context (all the children in a class etc..)?

 - Multiple nested contexts (each elephant role player is recursively assigned to a role in a "WalkInACircleContext" where they get two roles "Leader" and "Follower" )?

Got me a little confused that sentence..

Hope someone will be able to help me clarify this.

Vlad

 

[James O Coplien]

Let’s take all these people. Some are firemen. Some are factory workers. Some are nurses. Some are parents. That’s grouping (objects) by behaviour (what characterizes a role is a collection of behaviours).

[Vlad Lyga]

Well i get this part (role being a collection of behaviours).

The way it's written in the paper though, with "mixins cannot make all the elephants go in circle" (not an exact quote),

got me thinking - why? And then it's written thats because mixins don't allow grouping by behaviour.

But i think they are. Or i don't understand what grouping by behaviour is (on a implementation level of things). 

So i guess my question was a bit technical, how can i make all the fireman go on dancing in circle around their firetruck with DCI?

I always thought about roles as having a purpose in a use case. 

So yes, i can call all the "children" in the "class" to attention, and that i guess is a form of grouping (or like Trygve did with Node roles in his Dijkstra).

But all these "child"ren don't feel like 'real DCI' role to me.

Do i overcomplicate this? 

Its just that I really feel like i don't get that paragraph.

And i'm working with DCI for quite some time now, so how can i explain it to someone if i myself don't get it.

[Matthew Browne]

I think there may be different definitions of "mixins" floating around. When I think of mixins, I think of something like traits in Scala, but I'm not sure if that's what Cope was referring to in the paper - it sounds like he might be referring to something more limited than traits (it would probably be more obvious to someone with more knowledge of the history of mixins).

In any case, the thing that really distinguishes DCI from other approaches is that the roles are in a Context. With just mixins, there's no direct mapping between contexts / use cases and code, which also means there's no one place in the code you can look at to see how the roles interact with each other to achieve a particular use case.

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

[Vlad Lyga]

Thanks Matthew,

That's right, DCI roles are in in a Context. But "Fireman" is a Role that can appear in more than one Context, with different behaviour.

So DCI allows us to see only roles and their interactions only in a particular Context. 

I found that of itself to be of tremendous value. But i have a feeling that that is not what Cope meant...

[James O Coplien]

For elephants to go in a circle, Elephant A would have to know how to follow Elephant B. Those are objects. Mix-ins work with classes. There is no notion of object identity.

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

[Vlad Lyga]

Can i ask my original question again then, on a practical level when i try to write this program down:

I've got Elephant class.

ElephantA ... ElephantZ are objects instances of Elephant.

ElephantA ... ElephantZ are assigned to play TrainedElephant role in a ElephantCircleWalkStunt context.

Have CircleOfElephants role in ElephantCircleWalkStunt holding all the TrainedElephants.

Have ElephantTrainer role in ElephantCircleWalkStunt.

When executing 'ElephantCircleWalkStunt.start()' - the ElephantTrainer arranges the TrainedElephants in the CircleOfElephants,

and makes "CircleOfElephants.move()".

This is important for me for two reasons:

 1) I'm trying to expose as much people to DCI as i can, organising meetups and demos, and holding discussions.

     Therefore its important for me to able to explain this stuff.

 2) I have my humble PyDCI helper library/framework that i use for demos to let peple start exploring DCI without up-front investment.

      And it's imperative that all the DCI core abilities would be supported. Right now i don't have ability to assign multiple role players 

      to the same role in the same context. Never saw it necessary, but this article got me thinking so i want to make sure i get it.

[James O Coplien]

Den 12. feb. 2018 kl. 09.08 skrev Vlad Lyga <lyv...@gmail.com>:

Can i ask my original question again then, on a practical level when i try to write this program down:

I've got Elephant class.

ElephantA ... ElephantZ are objects instances of Elephant.

Check.

ElephantA ... ElephantZ are assigned to play TrainedElephant role in a ElephantCircleWalkStunt context.

Not in DCI they’re not. Maybe ElephantA is assigned to plan TrainedElephant1, and ElephantB to play TrainedElephant2, and so forth.

The role of an object is the name of an object according to its behavior. In any given use case there are not multiple objects playing the same role.

If the elephants are to be in a line then there is a first, second, … last, and the relationships and behaviors of each are unique. There is a finesse in the trygve language to further refine the equivalence sets into a first (for which one elephant plays the role), a last (ditto), and all the rest — which are represented as a role vector. All of them have the same behaviors, but are distinguished from the first and the last.

Try writing some code in trygve.

Have CircleOfElephants role in ElephantCircleWalkStunt holding all the TrainedElephants.

That’s a bit strange, but: O.K. If you wrote the use case, would this role appear?

Have ElephantTrainer role in ElephantCircleWalkStunt.

When executing 'ElephantCircleWalkStunt.start()' - the ElephantTrainer arranges the TrainedElephants in the CircleOfElephants,

and makes "CircleOfElephants.move()".

This is important for me for two reasons:

 1) I'm trying to expose as much people to DCI as i can, organising meetups and demos, and holding discussions.

     Therefore its important for me to able to explain this stuff.

 2) I have my humble PyDCI helper library/framework that i use for demos to let peple start exploring DCI without up-front investment.

      And it's imperative that all the DCI core abilities would be supported. Right now i don't have ability to assign multiple role players 

      to the same role in the same context.

Normally, you shouldn’t be able to do this. If you are in a restaurant and describing the behaviours adopted by the waiters so they don’t run into each other, then they need to play different roles: Waiter1, Waiter2, etc.. They can’t all do the same thing. But there is some finessing one can do, as mentioned above. It’s basically a syntactic shortcut. I don’t view it as part of the paradigm but as a convenience provided by the programming language.

Never saw it necessary, but this article got me thinking so i want to make sure i get it.

I think there’s an example in the trygve user manual.

On Monday, February 12, 2018 at 9:30:39 AM UTC+2, Cope wrote:

For elephants to go in a circle, Elephant A would have to know how to follow Elephant B. Those are objects. Mix-ins work with classes. There is no notion of object identity.

[Rune Funch Søltoft]

> Den 12. feb. 2018 kl. 09.08 skrev Vlad Lyga <lyv...@gmail.com>:
>

> ElephantTrainer arranges the TrainedElephants in the CircleOfElephants,
> and makes "CircleOfElephants.move()".

Having ElephantTrainer orchestrate that all elephants walk in a circle is very different from one elephants being able to follow another elephant.

A trait describes an ability. So a trait could describe the abilities a fireman should have but it doesn’t provide a single specific object anything. A role is objected centric not class centric, so the fireman trait says that there are some people who could be firemen, the role says this person is a fireman

[Matthew Browne]

On Mon, Feb 12, 2018 at 3:08 AM, Vlad Lyga <lyv...@gmail.com> wrote:

> Right now i don't have ability to assign multiple role players 

      to the same role in the same context. Never saw it necessary, but this article got me thinking so i want to make sure i get it.

 

Do you mean assigning multiple role players to the same role (in the same context) at the same time? That would be confusing.

 

On the other hand, if you are asking about binding an object to a role, and then later (within the execution of that same context) binding a different object to that same role, that is used in the activity frontloading example - we call it role re-binding. But some of us are skeptical as to whether allowing the re-binding of roles is a good idea in the first place.

[Quang]

a way to escape from class thinking.

[Vlad Lyga]

 

Have CircleOfElephants role in ElephantCircleWalkStunt holding all the TrainedElephants.

That’s a bit strange, but: O.K. If you wrote the use case, would this role appear?

In this very entertaining video one can clearly see that the elphants are guided by their trainers.

None of them is acting by himself.

https://www.youtube.com/watch?v=DRl-MLkXcTw&t=105s

So yes definitely , a Trainer is a role in a Context where the goal is to collaborate to achieve a given structure of elephants.

Have ElephantTrainer role in ElephantCircleWalkStunt.

When executing 'ElephantCircleWalkStunt.start()' - the ElephantTrainer arranges the TrainedElephants in the CircleOfElephants,

and makes "CircleOfElephants.move()".

Normally, you shouldn’t be able to do this. If you are in a restaurant and describing the behaviours adopted by the waiters so they don’t run into each other, then they need to play different roles: Waiter1, Waiter2, etc.. They can’t all do the same thing. But there is some finessing one can do, as mentioned above. It’s basically a syntactic shortcut. I don’t view it as part of the paradigm but as a convenience provided by the programming language.

Restaurants have the "master waiter" who assigns waiters to tables, and tasks dynamically.

But most importantly when spectators watch the show, during the stunt, they see and 'capture' only the whole ElephantCircle, not the individual elephants.

No one in the audience can distinguish between the First, or the Last.

For games such as military strategy it's the same - we have Soldiers, Soldiers make Units, Units make Armies.

So Elephants make a 'Unit' of kind 'ElephantCircle'.

Maybe the 'ElephantCircle' belongs to another Context...need to think about it.

[Vlad Lyga]

Having ElephantTrainer orchestrate that all elephants walk in a circle is very different from one elephants being able to follow another elephant.

It sure is different, no doubt. But how exactly is it different. 

A trait describes an ability. So a trait could describe the abilities a fireman should have but it doesn’t provide a single specific object anything. A role is objected centric not class centric, so the fireman trait says that there are some people who could be firemen, the role says this person is a fireman

This is great for conceptualizing about DCI, but on practice how can I deliver the message by example?

Roles are also written as classes. So for someone who doesn't spend a lot of time thinking about DCI - it looks like dynamic Trait. And in case of Scala it is a dynamic trait! 

So what is this 'grouping by behaviour' that is described in the paper, and how to achieve it in practice?

[James O Coplien]

Den 13. feb. 2018 kl. 10.09 skrev Vlad Lyga <lyv...@gmail.com>:

But how exactly is it different. 

Well, it depends on how you think about it.

There is no right and wrong here.

Write the code for each.

[James O Coplien]

Den 13. feb. 2018 kl. 10.09 skrev Vlad Lyga <lyv...@gmail.com>:

Roles are also written as classes.

No.

Role methods are scoped inside something called a Role, which syntactically looks like a class. But, unlike as with class names, one can associate a Role name with an instance. The Role name becomes a name for that instance — NOT for the static compile-time thing that declares the Role methods.

[Vlad Lyga]

On Monday, February 12, 2018 at 11:16:57 PM UTC+2, Matthew Browne wrote:

On Mon, Feb 12, 2018 at 3:08 AM, Vlad Lyga <lyv...@gmail.com> wrote:

> Right now i don't have ability to assign multiple role players 

      to the same role in the same context. Never saw it necessary, but this article got me thinking so i want to make sure i get it.

 

Do you mean assigning multiple role players to the same role (in the same context) at the same time? That would be confusing.

Yes very confusing, that the whole point of me in this thread.

That is what got me here is the phrase "group by behaviour" and "train elephants to follow each other in a circle".

 

On the other hand, if you are asking about binding an object to a role, and then later (within the execution of that same context) binding a different object to that same role, that is used in the activity frontloading example - we call it role re-binding. But some of us are skeptical as to whether allowing the re-binding of roles is a good idea in the first place.

I think re-binding can be very useful in some cases, wouldn't discard it as of now. 

[James O Coplien]

Den 13. feb. 2018 kl. 10.09 skrev Vlad Lyga <lyv...@gmail.com>:

So what is this 'grouping by behaviour' that is described in the paper, and how to achieve it in practice?

We can walk through it.

Start by writing the use case and then we’ll take next steps.

[James O Coplien]

Den 13. feb. 2018 kl. 10.13 skrev Vlad Lyga <lyv...@gmail.com>:

I think re-binding can be very useful in some cases, wouldn't discard it as of now. 

The problem is that you can’t guarantee / argue the proper binding of roles to objects. If you do the binding as a transaction, you can guarantee it.

[Vlad Lyga]

"which syntactically looks like a class" - that's why i said written like classes.

i'm taking here the perspective of the 'outsider' - the one who is presented with ideas of DCI and it all looks the same to him + some added syntactic sugar.

There's just stuff i cant explain right - i think it is because i myself don't understand it even after years.

I'm here to learn - and i am learning.

And thankful for that.

Seems my learning curve with DCI is something like that:

[Vlad Lyga]

You mean make binding atomic?

Because the initial binding should already be atomic, so i can 're-bind' by redoing the initial binding with another role player.

[James O Coplien]

Dunning-Kruger on pot :-)

[James O Coplien]

Den 13. feb. 2018 kl. 10.52 skrev Vlad Lyga <lyv...@gmail.com>:

You mean make binding atomic?

Because the initial binding should already be atomic, so i can 're-bind' by redoing the initial binding with another role player.

1. I strongly believe all roles should be bound together.

2. I much prefer that such binding be done once per Context instantiation.

There are those who disagree with both of these. Trygve violates #1 in some of his code (and, by inference, #2)

[Oleh Novosad]

Hi Vlad, 

I think when Jim was talking about mix-ins and how they are different to DCI he meant these ideas:

1. The concept of mix-ins says nothing about contexts - a place where roles are played. 

Quote:

"What mix-ins lack is a framework to tie

them together, and in particular to tie the mix-ins of one object with the mix-ins of another."

2. Roles can be dynamically assigned to objects (data) that have minimally viable "interface" or data to support that role. 

Mixins are assigned to classes and define the behavior of objects ahead of time (at compile time).

Quote:

"Each role is a collection of behaviors; what it means to be of a certain role is to be able to be grouped by that behavior.

Anything that is large, grey, has a trunk, and lives in trees must be able to play the role of an

elephant."

[Oleh Novosad]

Vlad, in your example: 

1. Elephant is Data for ElephantA ... ElephantZ instances and has no behavior. 

2. TrainedElephant is a role that can be dynamically assigned in context ElephantCircleWalkStunt to ElephantA ... ElephantZ instances

3.  CircleOfElephants role is a role for what Data instance? Array? I am not sure you need it.

4. ElephantTrainer role is a role for what Data instance? 

5. When executing 'ElephantCircleWalkStunt.start()' - Data instance that plays a role of ElephantTrainer makes ElephantA ... ElephantZ instances that play TrainedElephants roles move in circle by calling ElephantA.move_in_circle(), ... ElephantZ.move_in_circle() methods, where move_in_circle() is defined in TrainedElephants role. All this happens inside of ElephantCircleWalkStunt context.

[Vlad Lyga]

Thank you for your input Oleh.

3.  CircleOfElephants role is a role for what Data instance? Array? I am not sure you need it.
4. ElephantTrainer role is a role for what Data instance? 

If 'data instance' = role player.

Then i would like just to say that, i've found that sometimes

there is a role that is a 'helper role that is not played by 

any domain object (role player/data instance).

For example look here for Transcript = null in the Trygve borrow_library_panel2

https://github.com/jcoplien/trygve/blob/master/examples/borrow_library_panel2.k

[Matthew Browne]

On 2/19/18 7:47 AM, Vlad Lyga wrote:
> Then i would like just to say that, i've found that sometimes
> there is a role that is a 'helper role that is not played by
> any domain object (role player/data instance).
>
> For example look here for Transcript = null in the Trygve
> borrow_library_panel2
> https://github.com/jcoplien/trygve/blob/master/examples/borrow_library_panel2.k

BTW, the Context itself can also play a role. Although I'm not entirely
sure what considerations go into using the Context vs. null as the role
player in cases like this.

[Matthew Browne]

Cope, a question for you (not directly relevant to Vlad's question, just
something I thought of)...

The trygve language is designed to prevent role methods from calling
Context method. As I understand it, this is because after the initial
invocation of the Context, all subsequent operations should happen via
roles, according to the DCI paradigm (this also aligns with how use
cases work). But since the Context itself can play a role, it's possible
to circumvent this. Is that an acceptable loophole? What would be the
use case for it?

Thanks,
Matt

[Vlad Lyga]

Matthew what you ask is very interesting.
I haven’t ‘solved’ it in PyDCI yet , the whole Context as a Role is something that i’m still testing how to apply on practical level.
And one of the things i have right now, is that in my case Roles can access their Contexts methods.
Would certainly like to get insight about that, especially from Cope.

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

[James O Coplien]

Den 19. feb. 2018 kl. 13.47 skrev Vlad Lyga <lyv...@gmail.com>:

For example look here for Transcript = null in the Trygve borrow_library_panel2

https://github.com/jcoplien/trygve/blob/master/examples/borrow_library_panel2.k

What are we looking for?

[James O Coplien]

Hej, Matthew,

Den 19. feb. 2018 kl. 14.32 skrev Matthew Browne <mbro...@gmail.com>:

The trygve language is designed to prevent role methods from calling Context method. As I understand it, this is because after the initial invocation of the Context, all subsequent operations should happen via roles, according to the DCI paradigm (this also aligns with how use cases work).

Yup.

But since the Context itself can play a role, it's possible to circumvent this.

That is not "circumventing it,” unless by “it” you mean something at the Turing level of modeling computation. It is just proper trygve behaviour based on the facts that any instance (including a Context instance) can play a Role, and Role methods can invoke methods of other Roles in the same Context.

Is that an acceptable loophole? What would be the use case for it?

I often use this idiom if I find a Role that I think needs data (e.g., a method invocation counter). Those data can go in the Context and can be accessed with methods of a Role for which the Context is the Role-player.

[James O Coplien]

Den 19. feb. 2018 kl. 14.45 skrev Vlad Lyga <lyv...@gmail.com>:

And one of the things i have right now, is that in my case Roles can access their Contexts methods.

Can you show a reasonable use case that would be implemented with such a design?

[James O Coplien]

Den 19. feb. 2018 kl. 13.47 skrev Vlad Lyga <lyv...@gmail.com>:

For example look here for Transcript = null in the Trygve borrow_library_panel2

https://github.com/jcoplien/trygve/blob/master/examples/borrow_library_panel2.k

I should read more carefully.

Though the code is a bit strange in that the Role-player is null, there is nothing wrong with that. It’s certainly an edge case in that none of the class instance methods are ever invoked, and somewhat unusual in that the object is stateless. But it does have a perfectly good identity and is a locus of associated methods, so it makes a perfectly fine object. It just turns out that, in this use case, all the methods happen to work out fine as Role methods.

It may be that another domain analysis would create a new class with some of the methods we currently find in the Role, and with some history state or current-color or current-font state, and that we would have an instance of that class play the Role. This example is less sophisticated, which is why null works.

[Matthew Browne]

On 2/19/18 9:58 AM, James O Coplien wrote:

That is not "circumventing it,” unless by “it” you mean something at the Turing level of modeling computation. It is just proper trygve behaviour based on the facts that any instance (including a Context instance) can play a Role, and Role methods can invoke methods of other Roles in the same Context.

Is that an acceptable loophole? What would be the use case for it?

I often use this idiom if I find a Role that I think needs data (e.g., a method invocation counter). Those data can go in the Context and can be accessed with methods of a Role for which the Context is the Role-player.

Ah yes, for getter or setter methods for Context-level state I suppose it makes sense. I was thinking more of public methods of the context, or private context methods that would be better written as role methods...which is a matter of good design rather than something the language could enforce directly. Thanks for the explanation.

[Vlad Lyga]

No - that's just an unintended consequence of the implementation at this point. 

I'm personally not using it. But yes, the ability is there. For now.

[James O Coplien]

Hej, Vlad,

Den 19. feb. 2018 kl. 16.19 skrev Vlad Lyga <lyv...@gmail.com>:

No - that's just an unintended consequence of the implementation at this point. 

I'm personally not using it. But yes, the ability is there. For now.

One thing I’m carefully managing with trygve is whether to make it a tyrannical language or an anarchical language, or something in between. The problem with an anarchical language is that it will allow people to do non-OO things and to develop bad habits. The problems with a tyrannical language are 1. We are not yet sure we can formally prove that our way is the best, and 2. it dampens the purpose of the language as a research vehicle.

A recent example arose, which is that trygve allows re-binding Roles to objects after they once have been bound under control of the Context constructor (usually in a helper method called rebind or something like that). Leaving this totally open was based on the fact that Trygve does it in some of his code (he assigns a different object to a Role for each iteration of a loop) so I thought it might not be a totally verboten idea. It’s not clear this was the right choice — but, of course, we can change it. We can probably enforce the binding of all Roles to be atomic. That is a separate issue from deciding whether Roles and bind-once identifiers, and whether all Roles can be assigned en masse within a given context. Again, re-assignment is allowed because Trygve does this. I avoid it by recurring on Context instantiation, as I believe recursion is cleaner.

So I think carefully about leaving loose ends and frills in the language that could lead people to believe that DCI is something other than what it is. I’m not saying that should be your goal, but you might be conscious of whether that is or is not your goal.

— Cope

[Matthew Browne]

On 2/19/18 10:07 AM, James O Coplien wrote:

It may be that another domain analysis would create a new class with some of the methods we currently find in the Role, and with some history state or current-color or current-font state, and that we would have an instance of that class play the Role. This example is less sophisticated, which is why null works.

Interesting side-note: I suppose that in the case of a stateless role like this one, it doesn't matter whether you define it as a role or a stageprop (although it seems to me that a stageprop might be the safer and more readable choice).

[Vlad Lyga]

One thing I’m carefully managing with trygve is whether to make it a tyrannical language or an anarchical language, or something in between. The problem with an anarchical language is that it will allow people to do non-OO things and to develop bad habits. The problems with a tyrannical language are 1. We are not yet sure we can formally prove that our way is the best, and 2. it dampens the purpose of the language as a research vehicle.

A recent example arose, which is that trygve allows re-binding Roles to objects after they once have been bound under control of the Context constructor (usually in a helper method called rebind or something like that). Leaving this totally open was based on the fact that Trygve does it in some of his code (he assigns a different object to a Role for each iteration of a loop) so I thought it might not be a totally verboten idea. It’s not clear this was the right choice — but, of course, we can change it. We can probably enforce the binding of all Roles to be atomic. That is a separate issue from deciding whether Roles and bind-once identifiers, and whether all Roles can be assigned en masse within a given context. Again, re-assignment is allowed because Trygve does this. I avoid it by recurring on Context instantiation, as I believe recursion is cleaner.

So I think carefully about leaving loose ends and frills in the language that could lead people to believe that DCI is something other than what it is. I’m not saying that should be your goal, but you might be conscious of whether that is or is not your goal.

— Cope

I understand what you are saying, and I'm 100% with you on this. 

I have all the respect in the world for you and Trygve, and I feel that i have the responsibility towards you with regard to DCI. 

So yes - i definitely try to take 'extra care' to remain conscious, and cautious to faithfully represent DCI.

That is the actual reason i spend my time here, to be able to learn.

Only through this learning i get the needed insights that allow me to do the said needed "careful thinking".

Thank you.