<div dir="ltr"><div>Hi,</div><div> I really like double dispatch as technique but of course, as with everything, it has to be applied in the correct places, but it really helps with the open-close principle.</div><div> In cases where it really helped was when adding measure (like in Aconcagua). Being able to do "(1*meter) + 20" is great and we did have to change anything, we just implemented the right messages and worked. Doing the same in other smalltalks that do not use double dispatch was a little bit harder (he had to create an adapter and so on...).</div><div> I do not ascribe to the idea that programmers should be responsible for the types of the objects used in arithmetic operations. They can do it if they want of course, but the system should also take care of it if the user does not want to deal with that. Why should we do things the computers can do for us? I think the main reason for having computers is for them to do more and we less, although it is not really working that way lately 🙄🤔</div><div><br></div><div> Cheers!</div><div> Hernan.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 2, 2021 at 10:29 AM Luciano Notarfrancesco via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Interesting points. I agree that letting it fail when the two elements are from different rings is an option. But the idea of generality is not really mathematically rigorous, I don’t see how that could work with arbitrary rings for example. The reason it makes sense to convert an integer to an element of an arbitrary (unital) ring is because there’s always a canonical map (that’s the true nature of the integers, you could say), and in general between two rings the conversion makes sense only if there is a canonical map, that’s why I use double dispatch. The generality thing (pun alert) doesn’t work in general.</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 2 Jan 2021 at 7:17 PM, Ces VLC via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Yes, Luciano, now I did read the original 1986 minimalist paper by Ingalls about double dispatching (the one which is just 3-pages long), and the solution is elegant and clean. So, my disappointing is not about the technique, but about  applying it for type conversion. I mean, when a message is polymorphic in more than one variable (like in the example with geometric primitives and display devices that Ingalls uses in his paper), multiple dispatching is a clean and tidy approach when, for example, you use it for finding the actual implementation for drawing a rectangle on a printer, a circle on the screen, etc, so you avoid case trees that wouldn't be clean nor easy to maintain.<div><br></div><div>What I don't like is when this technique is used just for the purpose of type conversion: You don't have a different implementation for, say, adding an integer and a float. In binary arithmetic messages, multiple dispatching is not used for locating the proper implementation, because you have only one implementation (ie: integer+integer, float+float, etc). So, you use multiple dispatching as a trick for type conversion. That's not clean (it has nothing in common with the semantics used in the Ingalls paper), and, it's not efficient either (usually non-clean designs lead to inefficient solutions), as you incur in the penalty of two message lookups (indirections) for just the purpose of type conversion. The clean solution here, IMHO, is to make the programmer responsible for the types of objects in arithmetic binary messages and do any needed type conversions explicit. Alternatively, if the syntax of the expression must be free of explicit type conversion because of any design criteria, then the generality number approach doesn't look as untidy as double dispatch to me.</div><div><br></div><div>Thanks a lot for your comments, and kind regards,</div><div><br></div><div>César</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 2, 2021 at 6:20 AM Luciano Notarfrancesco <<a href="mailto:luchiano@gmail.com" target="_blank">luchiano@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="auto">IMO the double dispatch mechanism is pretty elegant, and I found it to work well even after extending Smalltalk to cover much more of mathematics.</div><div dir="auto"><br></div><div dir="auto">What I found more important is to make sure that every element has “parent”, an algebraic structure it belongs to. Then, if I try to do ‘a * b’ with a and b in two different rings A and B for example, the double dispatch mechanism looks for a canonical ring homomorphism A -> B or B -> A to convert one of the elements, and then resends the message with both elements in the same ring, works perfectly.</div><div dir="auto"><br></div><div dir="auto">Anyway, this is just implemented for convenience, in truth I don’t really need it and I could just raise an exception when trying to multiply two elements of different rings.</div><div dir="auto"><br></div><div dir="auto">In the base image there’s a little annoyance because of the automatic conversion of x/1 fractions to the integer x. I ended up creating a new class Rational and avoiding Fraction in my code, but it’s not a big deal for me, and the way Fractions work in the base image seems to be what most people expect.</div></div><div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 2 Jan 2021 at 12:52 AM, Ces VLC via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi again!<div><br></div><div>Being completely new to Smalltalk, I learnt about the "double dispatch" technique yesterday, and my first reaction was that I felt quite disappointed, because everything I was learning in Smalltalk was clean, tidy, and efficient, ...until I read about double dispatching.</div><div><br></div><div>Then I searched the Blue Book for double dispatching and found zero matches. Then I learnt Smalltalk-80 used "generality numbers" instead of double dispatching. With a bit more of searching, I found Cuis uses double dispatching because that change was done in Squeak by Ingalls time ago.</div><div><br></div><div>When reading the "generality numbers" approach in the Blue Book, I don't feel disappointed at all: it looks to me like the clean and obvious solution to the problem (ie: binary operators should be legal for objects of the same class only, and trying to perform a binary on different classes should trigger an error... however, if for some reason you want Smalltalk to do the conversion for you, the generality number approach doesn't break tidiness and pure design).</div><div><br></div><div>But I have a question, though: Did any of you have a long experience with Smalltalk-80 and found the generality number technique to be a limiting factor? I mean: Were your applications worse written (ie: with worse design) because of not having double dispatch?</div><div><br></div><div>I'd like to check whether Smalltalk without double dispatching is worse than with it, or not.</div><div><br></div><div>Thanks a lot,</div><div><br></div><div>César</div></div><div dir="ltr"><div><br></div></div>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div></div>
</div>
</blockquote></div>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div></div>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><span style="font-family:tahoma,sans-serif;font-size:xx-small;border-collapse:collapse"><strong><span style="font-size:8pt"><span><span style="font-size:small"><font size="2"><span style="font-weight:normal"><span style="font-weight:bold">Hernán Wilkinson</span><br>Agile Software Development, Teaching & Coaching</span></font></span></span></span></strong></span></div><div><span style="font-family:tahoma,sans-serif;font-size:xx-small;border-collapse:collapse"><strong><span style="font-size:8pt"><span><span style="font-size:small"><font size="2"><span style="font-weight:normal">Phone: +54-011</span></font></span></span></span></strong></span><font size="2" face="tahoma, sans-serif">-4893-2057</font></div><div><strong style="font-family:tahoma,sans-serif;font-size:xx-small"><span style="font-size:8pt"><span style="font-size:small"><font size="2"><span style="font-weight:normal">Twitter: @HernanWilkinson</span></font></span></span></strong></div><div><span style="font-family:tahoma,sans-serif;font-size:xx-small;border-collapse:collapse"><strong><span style="font-size:8pt"><span><span style="font-size:small"><font size="2"><span style="font-weight:normal">site: <a href="http://www.10pines.com/" style="color:rgb(17,65,112)" target="_blank">http://www.10Pines.com</a></span></font></span></span></span></strong></span></div><div><font face="tahoma, sans-serif"><span style="border-collapse:collapse">Address: Alem 896</span></font>, Floor 6, Buenos Aires, Argentina</div></div></div></div></div></div></div></div></div></div></div></div>