new chapter on double dispatch for new book :)

feedback is welcome
Good reading

Stephane Ducasse wrote:
> feedback is welcome
> Good reading

2.4

"is to explicit type check"
        - "is to explicitly type check", or
        - "is to do explicit type check"

s/we will haveother/we will have other/

s/distabilizing/destabilizing/

"In fact we just to tell the receiver ,,,"
        something's missing or is extra here


s/a die or an handle/a die or a handle/

Figure 2.1

I find the diagram strange on the first look. The solid arrow pointing
to the notes is the cause. I am used to see notes connected with dashed
line without a tip, an in UML.

2.6

Addition is commutative, so it should not bother form implementation
PoV, but it seems strange to see:

The previous method 􀑏 is definitively what we want to do when we have two
dice. So let us rename it as 􀃣􀃯􀃈􀁲􀂰􀃪􀂭􀀕􀂰􀂝􀏓 so that we can
invoke it later.
􀀕􀂰􀂝 􀐼􀐼 􀃣􀃯􀃈􀁲􀂰􀃪􀂭􀀕􀂰􀂝􀏓 􀂆􀀕􀂰􀂝
􀕫 􀀕􀂰􀂝􀀩􀂆􀃉􀂙􀃂􀂝 􀃉􀂝􀃻
􀂆􀂙􀂙􀀕􀂰􀂝􀏓 􀃣􀂝􀃂􀂧􀏞
􀂆􀂙􀂙􀀕􀂰􀂝􀏓 􀂆􀀕􀂰􀂝􀏞 􀄁􀃐􀃯􀃟􀃣􀂝􀃂􀂧

(eh? why pillar makes non copy-paste friendly pdfs?!)

back to the point, to see renaming + to sumWithDie: and keep the order,
and later do the magic and say "We just tell the argument (which can be
a die or a die handle) that we want to add to it an die.". Mind is
twisted when trying to grasp it as things are flipped.

Much better would be to say "So let us rename it as
􀃣􀃯􀃈􀁲􀂰􀃪􀂭􀀕􀂰􀂝􀏓 so that we can invoke it later but let us switch
the roles while doing it" and make the DD method with roles switched
(self added second).

Then the "We just tell the argument (...) that we want to add to it an
die." clicks much better (I would use "add itself to a die" in the end).

s/Easy, no./Easy, isn't it?/

"It is easy, isn’t?" - remove, too much of the same near each other

s/we simply creates a new die handle/we simply create a new die handle/

s/add all the die of the previous/add all the dice of the previous/

DieHandle >> sumWithDie: - also do reverse order and change the
description to be on par

2.7

s/the receiver is a die handle/the receiver of + is a die handle/
        With DD, things go there and back, better be explicit.

s/to add a die handle this time/to add itself to a die handle this time/

"We know what is to add two die handles"
        something is missing or extra here

We rename ... as ... => We rename ... as ... while switching roles.
        and reflect it in code

"Remember that sending back a new message to the argument is the key
aspect. Why? Because we kick in a new message lookup and dispatch."
        Not sure if this helps or confuses. Probably find better form.

s/final behavior just have to/final behavior we just have to/

s/withWithHandle:/sumWithHandle:/

Note: Die >> sumWithHandle: is in correct order, need no switching.

2.8

maybe s/trivial to understand deeply/trivial to deeply understand/

maybe s/it requires time to digest it/it requires time to digest/

maybe s/method based on the argument too/method based on the argument/

s/we step badk/we step back/

s/applied twice the Don’t ask, tell principle/applied the Don’t ask,
tell principle twice/

s/First the message 􀑏 plus selects/First the message 􀑏 selects/

s/selecting the correct method either W or Q/selecting either the
correct method W or the correct method Q/

s/the receiver and the argument of a messages/the receiver and the
argument of a + message/

Maybe in general sumWithFoo: => addSelfToFoo: to make clues clearer.

Herby

Tx I will read your point carefully.

On Wed, Aug 23, 2017 at 9:20 PM, Herby Vojčík <[hidden email]> wrote:
> Maybe in general sumWithFoo: => addSelfToFoo: to make clues clearer.
>
> Herby
>
>

On Wed, Aug 23, 2017 at 9:20 PM, Herby Vojčík <[hidden email]> wrote:
> Maybe in general sumWithFoo: => addSelfToFoo: to make clues clearer.

I see now it should be more
addSelfWithFoo: or sumSelfWith: because we do not modify the argument.

Stef

a die handle is a group of dice as in 2D20.
I'm not sure that I want to explain what is double dispatch up front.

I want to go from the requirements to the solution
How to add

die (6) + die(5)
die (6) + 2D20
2D20 + die(6)
2D20 + 2D10

Without doing a self class == Die
Stef


On Wed, Aug 23, 2017 at 1:38 PM, Dimitris Chloupis
<[hidden email]> wrote:

On August 23, 2017 10:09:02 PM GMT+02:00, Stephane Ducasse <[hidden email]> wrote:
>On Wed, Aug 23, 2017 at 9:20 PM, Herby Vojčík <[hidden email]> wrote:
>> Maybe in general sumWithFoo: => addSelfToFoo: to make clues clearer.
>
>I see now it should be more
>addSelfWithFoo: or sumSelfWithFoo: because we do not modify the argument.

I argue you should preserve original order of operands, otherwise there's a confusion that dd is only usable wjen you want to switch them. So with xWithY: form, it should addFooWithSelf: / sumFooWithSelf:.

Herby
>
>Stef

Ooops I wasn't int the mailing list, lets try again

Hello Steph,

I have questions about the concept because,probably, I miss something.
I am not sneaky, let me explain.

If we analyse the Kernel Numbers package, and we dissect the relation between Float, Fraction and Integer (Pharo 5.0) for example, the '+' method in the class Integer. We read:

+ aNumber
        "Refer to the comment in Number + "

        aNumber isInteger
                ifTrue: [ self negative == aNumber negative
                                ifTrue: [ ^ (self digitAdd: aNumber) normalize ]
                                ifFalse: [ ^ self digitSubtract: aNumber ] ].
        aNumber isFraction
                ifTrue: [ ^ Fraction
                                numerator: self * aNumber denominator + aNumber numerator
                                denominator: aNumber denominator ].
        ^ aNumber adaptToInteger: self andSend: #+

and we have similar '+'method containing complementary tests in the other class Float and Fraction.
And an overall '+' method in the class Number

+ aNumber
        "Answer the sum of the receiver and aNumber."

        self subclassResponsibility


I precise that a long time ago as an academic exercice, I developped a 'Complex' class using this way above (So I add tests).

My questions:
You say it's better to use double dispatch, so in this case, can we apply it for the Number subclasses?

It is good or unnecesary to create a super class 'Dicable' containing a '+' method with

+ aNumber
        "Answer the sum of the receiver and aNumber."

        self subclassResponsibility

? is it wasted time or safe code?

Yves

I start understanding better, I found this topic in the SmalltalkWithStyle book p. 107
This technic was explained by Dan Ingalls in
[Ingalls 86] Ingalls, D. A Simple Technique for Handling Multiple Polymorphism.
347-349, Proceedings of OOPSLA '86, Portland, Or., ACM SIGPLAN 21(11).
1986
That you can find here: https://pdfs.semanticscholar.org/4924/ecc75d2a30120a088740c53594065cae67ee.pdf

But about the Number class I need to understand the context deeper before understanding completely!

Yves

The code of Pharo for + **may** be rewritten using double dispatch but
it is not that clear to me
especially the adaptToInteger logic and we do not change for the sake of it :)
There are plenty of places we should improve and that are really important.

In Pillar, or compiler we have many more nodes and there a Visitor is
clearly the way to go.

Now you should try and sketch something and let us know.

There is not need to create a superclass between die and dieHandle
because DD is not based on nominal subtyping.
We just need objects proposing the correct API.

I use abstract superclass when I want to really push on contract or interfaces.
Now in this book I did not want to stress inheritance. So I wanted to
have a solution stressing messages because
often people forget that messages and polymorphism are powerful and
not systematically linked with inheritance.


Stef




On Tue, Aug 29, 2017 at 6:47 PM, Yves Lenfant <[hidden email]> wrote:

Yes I know this article.
For the book I was trying to get an example that I can just add as an
extension of a previous exercise.
And I like it.


On Tue, Aug 29, 2017 at 9:33 PM, Yves Lenfant <[hidden email]> wrote:

Thanks for your quick reply.
OK, your chapter highligths the polymorpism not the inheritance.

So I will try to change the Number methods in a dedicated image...

Anyway, in the book InsideSmalltalk P. 250, it explains that (I quote)

Conversion occurs in the direction (integer => fraction => float) ) in an attempt to maintain as
much accuracy as possible

I suppose the "Number" mecanism is more complex than I can expect.

Yves

Yes I like this book.
Now what I suggest is to try on a separate class hierarchy because
breaking + can blow up your image.

On Tue, Aug 29, 2017 at 10:28 PM, Yves Lenfant <[hidden email]> wrote: