new chapter on double dispatch for new book :)
I read it once without knowing what double dispatch is, after reading it , I did not know what double dispatch is. It took several reads to understand what double dispatch is. My suggestion is starting with explaining as a summary what double dispatch is , instead of leaving it for the conclusion, explain not how it works but why we need it. Its a good idea to give a general picture to the reader before a practical example as a map to follow the example more easily and not be lost in the code. The code is easy to understand but the intention is not. Also what is a "die handle" ? On Wed, Aug 23, 2017 at 1:54 PM Stephane Ducasse <stepharo.self@gmail.com> wrote:
feedback is welcome Good reading
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 <kilon.alios@gmail.com> wrote:
I read it once without knowing what double dispatch is, after reading it , I did not know what double dispatch is. It took several reads to understand what double dispatch is.
My suggestion is starting with explaining as a summary what double dispatch is , instead of leaving it for the conclusion, explain not how it works but why we need it. Its a good idea to give a general picture to the reader before a practical example as a map to follow the example more easily and not be lost in the code. The code is easy to understand but the intention is not.
Also what is a "die handle" ?
On Wed, Aug 23, 2017 at 1:54 PM Stephane Ducasse <stepharo.self@gmail.com> wrote:
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/
On August 23, 2017 10:09:02 PM GMT+02:00, Stephane Ducasse <stepharo.self@gmail.com> wrote:
On Wed, Aug 23, 2017 at 9:20 PM, Herby VojÄÃk <herby@mailbox.sk> 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 -- View this message in context: http://forum.world.st/new-chapter-on-double-dispatch-for-new-book-tp4963645p... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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.p... But about the Number class I need to understand the context deeper before understanding completely! Yves -- View this message in context: http://forum.world.st/new-chapter-on-double-dispatch-for-new-book-tp4963645p... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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 <lenfantyv@wanadoo.fr> wrote:
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.p...
But about the Number class I need to understand the context deeper before understanding completely!
Yves
-- View this message in context: http://forum.world.st/new-chapter-on-double-dispatch-for-new-book-tp4963645p... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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 <lenfantyv@wanadoo.fr> wrote:
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
-- View this message in context: http://forum.world.st/new-chapter-on-double-dispatch-for-new-book-tp4963645p... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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) I suppose the "Number" mecanism is more complex than I can expect. Yves -- View this message in context: http://forum.world.st/new-chapter-on-double-dispatch-for-new-book-tp4963645p... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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 <lenfantyv@wanadoo.fr> 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)
I suppose the "Number" mecanism is more complex than I can expect.
Yves
-- View this message in context: http://forum.world.st/new-chapter-on-double-dispatch-for-new-book-tp4963645p... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
participants (5)
-
Dimitris Chloupis -
Herby VojÄÃk -
herby＠mailbox.sk
-
Stephane Ducasse -
Yves Lenfant