<div dir="ltr"><div dir="ltr">Ken,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 28, 2019 at 10:06 PM <<a href="mailto:ken.dickey@whidbey.com">ken.dickey@whidbey.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">On 2019-04-28 17:57, Phil B wrote:<br> <br> > Ken,<br> > <br> > I'm not following your thinking here. What other implementations of <br> > things like #darker are you thinking of and how would renaming break <br> > encapsulation?<br> > <br> > As an example, let's say we had Form implement #darker which darkened <br> > the image and Color where #darker returns a new, darker color. I'd see <br> > that as semantic overloading, not polymorphism. And in the event we <br> > actually wanted the Form implementation to return a new, darkened Form, <br> > how would calling it #asDarkerForm break encapsulation? To me, that's <br> > just making it clear that you are not darkening the existing image but <br> > rather creating a new one... I still have no idea what's going on <br> > inside the object, only what I expect it to do/return.<br> <br> I tend to think of immutable, functional data structures. So I don't <br> expect 'foo darker' to return a mutable object.<br> <br></blockquote><div><br></div><div>OK, now I understand where you're coming from. I'd simply point out that in the vast majority of cases, Smalltalk code has not been nor is it currently immutable or functional 90+% of the time. If we wanted to make it be that, I'd be fine with it... as long as it were done consistently across the image and not just in islands/pockets.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> How would 'foo asDarker' help me?<br> <br></blockquote><div><br></div><div>To you and me in the short term, it doesn't. It's work to change functioning code. Over the long term, it helps as functionality gets added to the base image and packages get ported/created. I believe it would also help new users who are trying to figure out this whole Smalltalk 'thing' that people like us tend to go on about.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Why bother to go through a lot of working code and change #darker to <br> #asDarker to distinguish cases where uses of #darker returns a mutable <br> object?<br></blockquote><div><br></div><div>First: why bother? Because if we don't, we've either agreed that the generic #darker message (a one word unary, pretty valuable real estate) means one of:</div><div>a) implementors of it should return a new, darker copy of themselves. (doesn't sound very universally useful... are we sure we want to use up this name on it?)</div><div>b) implementors of it can do whatever makes the most sense to them ignoring what other implementors mean when they use it... names are meaningless.[1]</div><div><br></div><div>Second: a lot of work. Well, it's actually pretty trivial thanks to Hernan's refactoring work: you just load the base image with all packages and refactor a handful of method names... as long as there's no semantic overloading. (one benefit of avoiding semantic overloading: you don't have to worry about teasing apart overloaded method names to make changes like this. We've had previous refactorings like #value which I found quite painful to deal with largely because there is/was so much overloading.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> Where is the semantic distinction helpful?<br></blockquote><div><br></div><div>Everywhere.[2] I'd argue that if we don't minimize semantic ambiguities/overloading, Smalltalk quickly becomes a middling language at best since method names largely *are* the language.[3] The more one has to scratch their head and peek into otherwise working method implementations to answer questions like 'why the hell isn't this #foo working the way that other #foo does?', the less powerful/interesting Smalltalk is as a language. Also, isn't needing to either 'just know' or look inside a method to see why it's behaving differently encapsulation failure in a different direction? (instead of implementation details leaking out, you have to crack the method open and look at the implementation details to understand what is going on because the method name lied to you by doing something unexpected.)</div><div><br></div><div>[1] Use the source, Luke!</div><div><br></div><div>[2] I'm not saying it's the only or even the most important thing we have to worry about, but it is one of the important things.</div><div><br></div><div>[3] If in conversation I were to say "There there waiting for there friends at the club There" most people would have a difficult time following what I just said. But I'm not speaking so maybe this helps: "They're there waiting for their friends at the club, 'There'" (still not the easiest sentence to parse, but doable if one is reasonably proficient in English. Notice that written English tends to include hints in syntax, spelling and punctuation to help us parse things that sound the same) Granted, the VM doesn't care if we semantically overload otherwise identical syntax. But to the human reading/writing the code, if there are a handful of semantically different #darker methods, a dozen semantically different #foo methods etc. etc. Smalltalk can quickly degenerate into a word salad and becomes cumbersome for experienced users to follow and (more) confusing for new users to even get started. You don't get polymorphism by re-using a name, you get it by re-using the meaning that goes along with the name. The former without the latter is just operator overloading.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> -KenD<br></blockquote><div><br></div><div>Thanks,</div><div>Phil </div></div></div>