April 2019 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Richard Kenneth Eng is NOT Mr. Smalltalk

by horrido

I just accidentally came across this thread. I feel I have to provide some clarifications... First of all, the sobriquet "Mr. Smalltalk" started way back in October of 2016 with this article <https://medium.com/@richardeng/domo-arigato-mr-smalltalk-aa84e245beb9> . It was meant as a marketing gimmick to take advantage of the popularity of the Mr. Robot television series. I figured it would be a good way to attract attention. After all, /that's what marketing is all about/. I had no intention of making this an egotistical thing. I don't care to be a representative of the Smalltalk community. My one and only priority is to market Smalltalk any way I can, something that I made perfectly clear in the article and something that I have adhered to unwaveringly over the past several years. Second, I have never denigrated the contributions of the Smalltalk community. I applaud their efforts. However, I feel I must remain true to my mission: to market Smalltalk (and Pharo). People may disagree with my marketing strategy. That's fine. I cannot make everybody happy. But let's be very clear: many people also *agree* with my marketing strategy. So, who should I listen to? The answer is: nobody. On what basis would I allow others to influence my strategy? There is no central governing body for Smalltalk in all of its various incarnations (Pharo, Squeak, GNU Smalltalk, Dolphin Smalltalk, Cuis Smalltalk, VisualWorks, VA Smalltalk, GemStone/S, etc.). Trying to obtain consensus among such a broad range of communities would be pure folly. Third, I am entitled to my opinions, just as everyone else in this world is. My opinion is that Smalltalk (and Pharo) is a great language that deserves better marketing. There are some who disagree with me. Many people have told me that Smalltalk is moribund and way past its due date. I accept disagreement, but I don't have to let it stop me. My opinion is that JavaScript is a shit language. There are some who disagree with me. I accept disagreement, but I don't have to let it stop me. Michael Zeder is clearly a JavaScript fan. However, I can tell you that at Quora, where I often express my opinions about JavaScript, tens of thousands have upvoted my answers. In other words, there is tremendous support for my position. Again, who should I listen to? Let's be very clear about this: Only a JavaScript fan would be turned off by my opinions. JavaScript critics love me for them. It seems to me that Mr. Zeder's criticism of me is based almost entirely on the fact that he greatly admires JavaScript. Is that fair? Fourth, the culmination of my marketing campaign is JRMPC <https://jrmpc.ca> . After this, I'm done. Support for JRMPC has been quite positive. This was very clear at the Salta conference last November <https://hackernoon.com/my-keynote-at-the-salta-conference-435dfaccc888> . Vance Kershner of LabWare was impressed enough by my campaign to support me. At GoFundMe, none other than Alan Kay and Kent Beck also supported me. Alan Kay and Kent Beck!!!!! Whoa, that just blew my mind! So you know what? I don't feel I need to apologize for my efforts. I'm not seeking gratitude (though it would be nice to receive some). Finally, let me say, I'm not happy with my name showing up in SEO all over the place, either. I have never wanted to be the centre of attention. I wanted Smalltalk (and Pharo) to be in the limelight. But what I can do? That's the price I have to pay for marketing Smalltalk aggressively. I leave you with this Oscar Wilde quote: "There is only one thing in life worse than being talked about, and that is not being talked about." Hopefully, people are talking about Smalltalk. Ben Coman wrote > Hi Michael, > > Thanks for your thoughtful followup. > > On Fri, 1 Mar 2019 at 19:59, Michael Zeder < > post@ > > wrote: > >> >> I have carefully thought about, if I should really go publicly against >> one >> person within the community, and to start this "tirade", including the >> possibility that this causes an escalation, of course you cannot/must not >> silence a person ("Streisand" effect, did not know the term, but very >> fitting). But I decided that this kind of public conflicts is what is >> needed (and will make the community look better, not worse), _if_ a >> certain >> point is reached. >> > > I certainly subscribe to the tenet "Community standards do not maintain > themselves: They're maintained by people actively applying them, visibly, > in public." [1] > And I understand the tension in deciding to do so, with the accompanying > risk of making things worse (been there myself) > For me what weakened your first post was the name calling and sense you > were coming from a position of hurt with a story you needed to justify by > "making him wrong". :) > Much better second time round. > > [1] http://www.catb.org/esr/faqs/smart-questions.html#not_losing > > > >> I stand by it, but have reconsidered some points: >> * I do (did) not call for _immediate_ exclusion, but an "admonishment" >> that if certain behaviour is not about to change fundamentally, the >> community will have to act (by publicly separating this individual out). >> > * Take older articles down, which start flamewars against other languages, >> or more precise: separate them from Smalltalk advocacy! If he wants to >> flame JS (for its various birth defects), fine, but don't connect that >> with >> pro-Smalltalk articles, for example. >> > > That seems a reasonable position and a good way to frame it. > > > >> * Community efforts shall follow follow some community consensus. Core >> developers are no dictators, of course, but they are the ones knowing, >> what >> the state of the project is, and where _their_ work will lead to. >> Constantly ignoring this common guidance is detrimental to the community. >> So either, learn Smalltalk core coding and challenge the leadership, or >> do >> accept that there is some common agenda (and there are lots of open >> tasks: >> writing tutorials, documentation, make old scientific research available, >> linking and connecting showcases). >> > > His earlier articles got hammered and its natural that created a defensive > position for him to disconnect from the community leadership. > The trick as for everyone is to not carry those forever and try starting > anew. > > > * Public opinion does matter. The fact I mentioned Google SEO was indeed >> the starting point for me, to get into or start this flame war. *Here is >> my story*: >> Two of my clients (medium-sized enterprises) are classical C++/C# Windows >> development companies. I advertised Pharo to them for an _internal_ tool >> (their commerical products won't change to Smalltalk of course, but for >> their own internal dev tasks, Pharo whould have been a nice fit). When >> the >> managers got back to me, *they had googled it, and told me, this thing >> sounds very dubious ("unseriÃ¶s"). I enquired, what they had read, and >> they >> told me, this "spokesperson" (sic!!!) sounds like a trolling script kid, >> and they can't employ something which is developed (sic!!!) by such >> people*. >> After some explanation, I managed to convince them, that this person is >> just a lonely person, who showed up out of nowhere, is not involved in >> the >> actual work, and just produces himself on the internet. But too late, >> their >> impression on Smalltalk was already formed by R.K.Engs "blogs" (in the >> meantime, they rank on top in Google search result). >> > > You should have led with that !!!! An experience has a lot more power > than > an opinion. > > > >> When I did some research of my own yesterday, and saw again, that R.K. >> Engs dubious blog entries were listed on top, I decided to take action. >> >> >> I like to answer to your balanced and thoughtful responses: >> >> You may disagree about *how* he does such work, the actual content, for >> sure, but that's a feedback better directed to mr. Eng himself. >> >> >> R.K. Eng has made it clear in the past many many times in uncertain >> wording, that he is not willing to follow community advice in these >> matters, if his gut is telling him something different... >> >> > Some of that community advice has been delivered fairly confrontation-ally > and not really conducive to having someone listen. > > >> Hopefully I've expressed a balanced enough position that this doesn't >> draw >> too many responses. >> >> yes, you did. thank you. >> >> >> I agree "Mr Smalltalk" is quite a presumptive title, but really anyone >>> following the mail lists soon gets an idea of who are the community >>> merit >>> leaders. >>> >> >> Well, I disagree, based on the experience, I have written down above. The >> internet is very much about who is in the center of the focus (SEO/social >> media). Anybody new to Smalltalk will at first glance identify our >> community with this "spokesperson" (as I have experienced with two >> people, >> last year already btw) >> > > Point taken. > > > Maybe it is a language thing, but "Mr. Smalltalk" is _extremely_ >> presumptive (in German, it means the embodiment of the denoted thing). If >> a >> person is not doing very very thorough reading of ages old mail list >> discussions or is researching, that this person in fact never committed >> any >> code to the repos, then any newcomer will think, this "Mr. Smalltalk" is >> at >> least a versed and informed Smalltalk developer (which, given his newbie >> questions he is absolutely not). >> > > Got it. So apart from fighting directly against his presumption to the > title (which seems difficult) > would cleaning some other-language-denigration from old articles go some > way towards mitigating your concern? > > >> You are right he hasn't committed any code, but I've not actually seen >> him >>> claim credit for any code in Pharo, so this point seems off. >>> >> true. but as I just wrote, that is what people presume, given his way and >> manner of producing himself. If he wrote honestly wrote "I am a fanboy, >> supporter and advocate of Smalltalk...", great! But he claims he worked >> many many hours without a dime, but worth many dollars, and had >> "tremendous >> success" in creating a new Smalltalk wave. >> > > I'm pretty by many-hours-without-a dime he meant his evangelism. > If it didn't come across like that, that is probably specific copy-edit > feedback that would be useful to him. > > >> * ...is doing SEO to make Google show his own results before FOSS >>>> community or sciences pages. >>>> >>> I think its equally likely that most in our community are too busy >>> coding >>> to try getting articles ranked, >>> so its more lack of effort by most of us. Most of his articles mention >>> Pharo so people end up finding us anyway. >>> >> might be true (some criticism to the community agenda..? different topic) >> The thing is, the wrong information are getting more and more in the >> focus >> of the internet, pushing aside the community-driven Pharo sites (or real >> scientific papers or well-done tutorials). >> > > I've read most of his articles. I don't think he gets much factually > wrong > about Pharo (and has corrected those when pointed out). > It seems your main concern about wrong information is attacks on other > languages, which is fair. > > > >> Any money he gets for his writing is not anything that concerns me >>> personally. Those articles are his own effort. >>> >> >> Sorry, misunderstanding! Of course, he may earn with his writing, >> whatever >> he gets for it. >> I was referring to the "up-coming" Smalltalk Coding Competition. >> > > btw, a few weeks ago when Richard asked for help to program the > competition, I volunteered. > I've criticized some of his articles, and maybe there are other "better" > the money could be spent, > but I admire he has stuck to his vision and think its a big thing he has > taken on. > If its going to happen anyway, for me its better to help make it a success > than a flop. > [Sidebar: I haven't managed to do much on it yet since I'm run ragged on a > personal development course until mid-April > that includes running a community project of my own... > https://www.nanpopcode.fun/] > > > >> Now, yes, that money doesn't go into his own pockets (would be criminal >> fraud), but the thing is, he controls this money. >> > Who will be the judges? Who will set parameters for the competition? >> Transparency? >> > What is the benefit that goes back into the community? Now, it is fine, >> that he is pushing for things like that, but again, he is doing it >> without >> synchronising this effort with what is needed by the community. >> > > He got a reasonable number of supporters on GoFundMe (I wasn't one at the > time), > and I believe the majority of the money comes from a few companies > so I expect its really their opinion that counts about how their money is > spent. > > > >> * ...denies community leadership by merit (Pharo core developers do know, >>>> what they have created and where they want to go in the future, >>>> >>> I don't see him claiming leadership of our community or trying to set >>> our >>> agenda. >>> He just didn't let community criticism of his writing slow him down. >>> All I observed is that several people bit him and he bit back - fairly >>> usual sort of poor communication on both sides (including me). >>> >> >> Well, as written above, the manner of his web appearance is implicitly a >> claim of community leadership. Not an exclusive one of course, but he >> wants >> to be perceived of one of the most important persons in the community (he >> told so many times, explicitly). And given my experience, read above, >> this >> had already a (negative) success with it. >> And I think he is setting agenda: "Make Smalltalk great/mainstream again" >> is the baseline, and that is something, only the core dev team and the >> community as a whole can decide/make happen (I love Smalltalk, but he >> promises wrong things, so if, just for example, C++/Qt devs or _modern_ >> JS >> devs have a first look at Smalltalk with the expectation they could >> already >> do the same thing as in their usual platforms, they will be disappointed >> --> synchronize a marketing agenda with what this great project currently >> is about, but he is not willing to cooperate with the core dev team) >> > > Fair enough. Since in a couple of months I'll be helping him out, I'll > have an opportunity to raise these concerns with him. > > >> Him swearing about a group of Pharo people is good ammunition to bring to >>> the mail list to support your point, >>> but I also see he was rather provoked. Overall I feel this extract was >>> better left in that small corner of the internet >>> rather than fan flames here. >>> >> >> :) Yeah... no! I think this is really a central point (so I put him in >> the >> pillory here with intent). There is something called community/FOSS >> ethics >> and structures. >> He does not show _respect_ towards those people, who did the work, but >> produces himself, and pushes for things, which the people who devoted >> their >> work to this project, told him that it is counter-productive. That is, in >> the long-run, a very dangerous situation. >> > > I agree, its not great. But he didn't get a warm welcome and some of his > early interactions were abrasive. > Considering two extremes, you can either be inclusive and hopefully > nurture/mold, or exclude and lose any chance at that. > Like a lot of things, the path is somewhere in the middle and needs a bit > of give and take on both sides. > > >> PS: a side note on Javascript (with lower S). wether you love or hate >> this >>>> quirky lovechild of Lisp and Self/Smalltalk, telling JS developers they >>>> are >>>> stupid and that they should abandon powerful Vue.js, for example, in >>>> favor >>>> of Amber Smalltalk [cudos to Amber devs! great thing!]) is utterly >>>> stupid! >>>> >>> Agree. But banning everyone in the world for similar stupidity would >>> leave the internet awfully quiet. >>> >> Sure! Again: I am against silencing or banning anybody (and how could >> you). But if this becomes unbearable, there needs to be a public >> separation, so he does not drag the project down. People need to speak up >> against such usurpation. >> > > I appreciate the stand your are taking for the community. > I've gained from your share of your workplace experience. > > (which in the end are only a self-serving, ego-centric, attention-greedy >>>> campaign to promote "Mr. Smalltalk" himself, a total newbie, who claims >>>> credit for the work of others). >>>> >>> Your repeated "claims credit for the work of others" is quite >>> provocative >>> and I haven't noticed this in his writings. Could you provide a link? >>> >> >> See above, maybe it is a cultural thing, but as I told in my experience, >> all of his appearance screams for being recognized as one of the most >> important persons in the community (he is condescendingly mocking >> marketing >> efforts of the last 40 years, claims that he is the one who will "make >> smalltalk great again"...) >> >> Yes I am provocative this time, not my normal style (and I admit, I was >> tripped-out by his provocative blog title "Even people who understand >> prototypal programming do not like it â an inconvienent truth"; that is >> dripping off arrogance and ignorance... And sheds a bad light on >> Smalltalk, >> with which he wants to be identified in the web) >> > > Got it. > Let me ask to park this thread for the moment, because it can be quite > distracting if everyone chips in an opinion. > I think you've made some fair points and I'll put myself on the line to > discuss them with Richard when I start helping him with his competition > project. > > cheers -ben -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 9, 2019

Screencasts on Debugger driven development

by stephan

Some work Vincent Blondeau and I have been doing on the Taskbar has inspired me to make some screencasts showing how to do debugger driven development, and take the first steps towards refactoring the TaskBarMorph, driven by tests. Part 1 https://vimeo.com/329317634 Part 2 https://vimeo.com/329368348 Stephan

April 9, 2019

Re: [Pharo-users] difference between double dispatch and the method explains here

by Roelof Wobben

April 8, 2019

Re: [Pharo-users] difference between double dispatch and the method explains here

by Richard O'Keefe

You are expected to use my code fragments for *ideas*, not to incorporate them *literally* in your code. As I explained, *without seeing the specification*, I have no way to tell whether the specification uses a left-handed or right-handed coordinate system. For what it's worth, here's a complete program in my Smalltalk dialect. It doesn't plug into the exercism testing framework because I can do not know what it looks like. But if it makes the code more complicated that this, it's doing it wrong. require: 'geometry.st' "Point" require: 'print.st' "OutputStream>>print:" Object subclass: #Robot instanceVariableNames: 'position direction' poolDirectionaries: 'FileStream' methods for: 'initialising' pvtPostNew position := 0@0. direction := 1@0. methods for: 'accessing' direction ^direction copy location ^location copy obey: commands commands do: [:each | each caseOf: { [$A] -> [position := position + direction]. [$L] -> [direction := direction leftRotated]. [$R] -> [direction := direction rightRotated] }]. class methods for: 'main' start [StdIn atEnd] whileFalse: [ |robot| robot := Robot new. Robot obey: StdIn nextLine. StdOut print: Robot location; cr]. On Tue, 9 Apr 2019 at 02:58, Roelof Wobben <r.wobben(a)home.nl> wrote: > yes, this is a real tests from the pharo track on exercism.io > > I understand what you mean but maybe I overthinking things. > But if we have a robot facing north and the robot turns to the left , im > my oponion it faces now to the east. > > like this test is saying : > > > test04_RotatesTheRobotsDirection90DegreesClockwiseChangesTheDirectionFromEastToSouth > | result | > result := robotSimulatorCalculator > moveDirection: 'east' > position: > (Dictionary new > add: 'x' -> 0; > add: 'y' -> 0; > yourself) > instructions: 'R'. > self > assert: result > equals: > (Dictionary new > add: 'direction' -> 'south'; > add: > 'position' > -> > (Dictionary new > add: 'x' -> 0; > add: 'y' -> 0; > yourself); > yourself) > > > but I cannot come to the same outcome with this code : > > > pointToName: aPoint > ^aPoint x isZero > ifTrue: [aPoint y > 0 ifTrue: [#north] ifFalse: [#south]] > ifFalse: [aPoint x > 0 ifTrue: [#west ] ifFalse: [#east ]] > > > maybe exercism.io is not a good way to practice and learn smalltalk but I > found not a better one. or smalltalk is not for me. > > Roelof > > > > > > > > > > > > Op 8-4-2019 om 16:44 schreef Richard O'Keefe: > > The basic issue here is abstraction. > An instance of "Robot" in your program is not a > physical object. How could it possibly point North, > South, or Nor-nor-west? It cannot. > Its location and direction are abstract values > *metaphorically* related to real world notions > like position vectors and velocity vectors. > "North" in this program is not a real thing, > it is an *idea* which could be represented by > 'North', 'north', #North, #north, $N, $n, > 'Raki', 'raki', #Raki, #raki, $R, $r, > 137, (0@ -1), a picture of the star Polaris, > the colour red (the conventional colour for > that end of a compass needle which points north), > a sound recording of a lecture by Alfred North > Whitehead, or anything you please, as long as, > inside the program, it *acts* the way *you* want > "north" to act (which is not necessarily the way > the physical direction North acts, and in fact in > this case it most certainly is not). > > Locations and movements in a 2D space are, in Smalltalk, > commonly represented by Points. "Represented by." > > As for this method: > > > test11_MovesTheRobotForward1SpaceInTheDirectionItIsPointingIncreasesTheYCoordinateOneWhenFacingNorth > | result | > result := robotSimulatorCalculator > moveDirection: 'north' > position: > (Dictionary new > add: 'x' -> 0; > add: 'y' -> 0; > yourself) > instructions: 'A'. > self > assert: result > equals: > (Dictionary new > add: 'direction' -> 'north'; > add: > 'position' > -> > (Dictionary new > add: 'x' -> 0; > add: 'y' -> 1; > yourself); > yourself) > > PLEASE tell me that is not what they are actually using. > Let's start with > (Dictionary new) > add: k1 -> v1; > ... > add: kn -> vn; > yourself > Did you know that sending #add: to a dictionary is not > portable? Storing actual Association objects inside > Dictionaries was originally an encapsulation error and > remains a performance error, so there are Smalltalks > that do not make that mistake. The *portable* way to > make a Dictionary is > (Dictionary new) > at: k1 put: v1; > ... > at: kn put: vn; > yourself. > > And why in the name of sanity are the keys *strings* > instead of *symbols*? This is not Smalltalk. It is > Javascript in drag. > > Now exercism.io has a habit of insisting on particular > implementations. For example, I completed the SML track, > and found that the test code ONLY worked with Poly and > not with any of the three SML implementations I already > had on my machine. Since you are doing this in Pharo, > I take it that exercism.io will insist on the Smalltalk > track being done in Pharo, and in that case it is > *nauseating* to use a Dictionary when you could use a > Point. Old-fashioned Smalltalk style would have been > to return something like > #(<direction> <x> <y>) > e.g. #(north 1 0), and I still prefer that. > > In fact *good* Smalltalk style for something like this > would be > > test11_MovesTheRobotForward1SpaceInTheDirectionItIsPointingIncreasesTheYCoordinateOneWhenFacingNorth > robotSimulatorCalculator > moveTo: 0@0; > head: #north; > obey: 'A'. > self assert: robotSimulatorCalculator heading equals: #north. > self assert: robotSimulatorCalculator location equals: 0@1. > > -- We're starting to get the idea that identifiers like > robotSimulatorCalculator are not a very good idea when > simulatedRobot would do the job as well or better. > > (This is also pointing us towards Betrand Meyer's > Command/Query Separation principle, but we shan't > go there today.) > > This is important feedback to give to the exercism.io > people. The test code should use a SMALLTALK interface, > not a warmed-over JAVASCRIPT interface. > > Now, how do we map between direction *names* and > direction *points*? Well, we have to start by > laying down clearly what we *mean* by the directions. > > To move North one step is to add 1 to y and 0 to x. > (We know that from the appalling test case above.) > To move South one step is to add -1 to y and 0 to x. > (South is the opposite of North.) > To move East one step, oh we have a problem. > THIS NEEDS SPELLING OUT. And one of the things the > exercism.io exercises are HORRIBLY BAD AT is specifying > the problem. Nearly every single exercise I have tried, > I have been unable to tell what the problem is without > examining the test cases, and that is not the way > exercises are supposed to work. (Yeah, that's why I'm > screaming about it. I've taught a class using exercises > like this that were not of my writing and vague specifications > really upset the students. People who had taken the class > under someone else several years before were still angry > about it.) > > The geometric classes in Smalltalk were written to support > graphic user interfaces. And in user interfaces, the y > coordinate increases DOWN. So if we take the compass rose > and rotate it so that North is DOWN, it follows that > West is right and East is left. So > > To move East one step is to add -1 to x and 0 to y. > To move West one step is to add 1 to x and 0 to y. > > The chances are excellent that the problem specification > is inconsistent with this. Sigh. Let's proceed, though. > > North 0@1 > South 0@ -1 > East -1@0 > West 1@0 > > > pointToName: aPoint > ^aPoint x isZero > ifTrue: [aPoint y > 0 ifTrue: [#north] ifFalse: [#south]] > ifFalse: [aPoint x > 0 ifTrue: [#west ] ifFalse: [#east ]] > > nameToPoint: aSymbol > aSymbol = #north ifTrue: [^0 @ 1]. > aSymbol = #south ifTrue: [^0 @ -1]. > aSymbol = #west ifTrue: [^1 @ 0]. > aSymbol = #east ifTrue: [^-1 @ 0]. > aSymbol error: 'not a compass direction in lower case'. > > Another problem I had with exercism was a "Space-Age" > exercise where the README.md capitalised the planet names > but test_Space-Age.<whatever> insisted on lower case. > That might well happen here. > > Just for grins, > Dictionary>> > asPoint > ^(self at: 'x') @ (self at: 'y') > > Point>> > asDictionary > ^(Dictionary new) > at: 'x' put: self x; > at: 'y' put: self y; > yourself > > > > > On Mon, 8 Apr 2019 at 22:15, Roelof Wobben <r.wobben(a)home.nl> wrote: > >> Richard thanks. >> >> One thing I do not see direct. >> >> you said : >> >> >> A direction could be represented by a pair of integers >> dx, dy such that |dx|+|dy| = 1. It could also be >> represented by a Point with integer components. >> >> for me a direction is the direction the robot is facing so something like >> north or east. >> >> the challenge also wants a output like this : >> >> >> test11_MovesTheRobotForward1SpaceInTheDirectionItIsPointingIncreasesTheYCoordinateOneWhenFacingNorth >> | result | >> result := robotSimulatorCalculator >> moveDirection: 'north' >> position: >> (Dictionary new >> add: 'x' -> 0; >> add: 'y' -> 0; >> yourself) >> instructions: 'A'. >> self >> assert: result >> equals: >> (Dictionary new >> add: 'direction' -> 'north'; >> add: >> 'position' >> -> >> (Dictionary new >> add: 'x' -> 0; >> add: 'y' -> 1; >> yourself); >> yourself) >> >> so how do I "convert" the point you are using to the text. >> >> Or do I misunderstood you somewhere wrong. >> >> Roelof >> >> >> >> >> Op 8-4-2019 om 10:57 schreef Richard O'Keefe: >> >> One thing I have often seen and lamented is students >> writing excessively complicated code with way too many >> classes. There is a huge difference between >> "A Robot knows its position and direction." >> and >> "A Robot has-a Position and has-a Direction." >> The first is the important one. The second is >> an over-commitment to too many classses. For a >> problem like this, you really really do not want >> a Direction class, and you certainly have no use >> for double dispatch. >> >> A position can be represented by a pair of integers >> x, y. It could also be represented by a Point with >> integer components. >> >> A direction could be represented by a pair of integers >> dx, dy such that |dx|+|dy| = 1. It could also be >> represented by a Point with integer components. >> >> For movement, you need to be able to add the direction >> to the location, which could be simply >> x := x + dx. y := y + dy. >> or it could be >> position := position + direction. >> For turning, you need to be able to rotate a direction >> vector by ninety degrees. Now it so happens that >> Point has methods #leftRotated and #rightRotated. >> >> So we can do the following: >> a Robot has position (a Point) and direction (aPoint) >> position := 0 @ 0. >> direction := 0 @ 1. >> To move forward without turning: >> position := position + direction. >> To turn left without moving: >> direction := direction leftRotated. >> To turn right without moving: >> direction := direction rightRotated. >> To obey a sequence of characters, commands: >> commands do: [:each | >> each caseOf: { >> [$A] -> [--move forward--]. >> [$L] -> [--turn left--]. >> [$R] -> [--turn right--] >> }]. >> >> >> One of the key ideas in extreme programming is >> "You Ain't Gonna Need It", abbreviated to YAGNI! >> The idea is *DON'T* generalise beyond your immediate >> needs. In this case, for example, the likelihood of >> *this* program needing to deal with more general >> kinds of movement is ZERO. And the only reason for >> using Point here instead of just using a few simple >> assignment statements is that Point already exists, >> so costs nothing to write, and as a familiar class, >> code using it should be easy to read. >> >> If someone challenges you to do something counter-productive, >> refuse the challenge. >> >> On Mon, 8 Apr 2019 at 17:21, Roelof Wobben <r.wobben(a)home.nl> wrote: >> >>> I can try to explain what I trying to solve. >>> >>> I have a Robot which can turn left, turn right or moveForward. >>> >>> now I have a string like 'LAR' >>> >>> that means the robot needs to turn left (l) , move forward one place (A) >>> and turn left. >>> and I have to keep track to which direction the robot is facing and on >>> which coordinate it stands. >>> >>> so to summarize with the above string >>> >>> lets say the robot is facing north on coordinate (0,0) >>> then it has to turn left , so its facing east and still on coordinate >>> (0,0) >>> then it has to move forward, so its still facing east but are on >>> coordinate(0,1) >>> then it has to turn right, so its facing north and on coordinate (0,1) >>> >>> and TimMacKinnon has challenged me to do this with double dispatch. >>> >>> So I think now I need a object Direction, a sub object North and a sub - >>> sub object TurnLeft, turnRight and moveForward. >>> >>> So I can use double dispath first the direction North, East, South, West >>> and then use double dispatch to find the right move. >>> >>> Roelof >>> >>> >>> >>> >>> >>> Op 8-4-2019 om 06:50 schreef Richard O'Keefe: >>> >>> It would really REALLY **REALLY** help if we knew what >>> the heck you were trying to do. There is an excellent >>> chance that it is MUCH simpler than you think. If you >>> cannot show us the Smalltalk version of the problem, >>> can you show us the version for some other language? >>> >>> >>> On Sun, 7 Apr 2019 at 20:15, Roelof Wobben <r.wobben(a)home.nl> wrote: >>> >>>> Op 6-4-2019 om 15:15 schreef K K Subbu: >>>> > On 06/04/19 4:49 PM, Roelof Wobben wrote: >>>> >> Hello, >>>> >> >>>> >> I just learned double dispatch. >>>> >> And now for the Robot challenge of exercism Tim has pointed me to >>>> >> this >>>> >> article( >>>> https://blog.metaobject.com/2019/04/accessors-have-message-obsession.html) >>>> >>>> >> >>>> >> but I fail to see how the move method looks like in that article. >>>> >> I had a conversation with Tim in the exercism channel and the way he >>>> >> explains it, it looks like double dispatch for me. >>>> >> >>>> >> Am I on the right track or do I oversee something here. >>>> > unary methods like moveRight perform specific ops and are not >>>> > parametric, so only a single dispatch, depending on the receiver, is >>>> > needed. >>>> > >>>> > If you change it to move: aDistanceOrAngle, then performing requests >>>> > like "move: 3 cms" or "move: 30 degrees" will depend not only on the >>>> > receiver but also on the class of the argument. This would need >>>> double >>>> > dispatch (aka multiple polymorphism). The first dispatch would be >>>> > based on the receiver and the receiver's method would then dispatch >>>> it >>>> > based on the class of the argument (i.e. Distance>>move or >>>> Angle>>move ) >>>> > >>>> > HTH .. Subbu >>>> > >>>> > >>>> >>>> >>>> hmm, still stuck >>>> >>>> I have now a class Direction with as instance variables north, south, >>>> east, west >>>> and made the accessors. >>>> >>>> then I thought I need a initialize like this : >>>> >>>> initialize >>>> north = Direction( 0, -1). >>>> east = Direction( 1, 0). >>>> south = Direction( 0, 1). >>>> west = Direction(-1, 0). >>>> >>>> but the Direction (0,-1) is a problem . the compiler does not like the >>>> (0,-1) part >>>> >>>> to give you the big picture. I have a Robot which can turnRight , >>>> turnLeft and moveForward and I try to understand how the page would >>>> work >>>> in my case. >>>> >>>> So I have a object Direction as described above and a Object >>>> MoveForward >>>> which is a subobject of Direction. >>>> MoveForward has only 1 method : >>>> >>>> IsMove >>>> ^ 'A' >>>> >>>> Roelof >>>> >>>> >>>> >>> >> >

April 8, 2019

Re: [Pharo-users] difference between double dispatch and the method explains here

by Roelof Wobben

April 8, 2019

Re: [Pharo-users] difference between double dispatch and the method explains here

by Richard O'Keefe

The basic issue here is abstraction. An instance of "Robot" in your program is not a physical object. How could it possibly point North, South, or Nor-nor-west? It cannot. Its location and direction are abstract values *metaphorically* related to real world notions like position vectors and velocity vectors. "North" in this program is not a real thing, it is an *idea* which could be represented by 'North', 'north', #North, #north, $N, $n, 'Raki', 'raki', #Raki, #raki, $R, $r, 137, (0@ -1), a picture of the star Polaris, the colour red (the conventional colour for that end of a compass needle which points north), a sound recording of a lecture by Alfred North Whitehead, or anything you please, as long as, inside the program, it *acts* the way *you* want "north" to act (which is not necessarily the way the physical direction North acts, and in fact in this case it most certainly is not). Locations and movements in a 2D space are, in Smalltalk, commonly represented by Points. "Represented by." As for this method: test11_MovesTheRobotForward1SpaceInTheDirectionItIsPointingIncreasesTheYCoordinateOneWhenFacingNorth | result | result := robotSimulatorCalculator moveDirection: 'north' position: (Dictionary new add: 'x' -> 0; add: 'y' -> 0; yourself) instructions: 'A'. self assert: result equals: (Dictionary new add: 'direction' -> 'north'; add: 'position' -> (Dictionary new add: 'x' -> 0; add: 'y' -> 1; yourself); yourself) PLEASE tell me that is not what they are actually using. Let's start with (Dictionary new) add: k1 -> v1; ... add: kn -> vn; yourself Did you know that sending #add: to a dictionary is not portable? Storing actual Association objects inside Dictionaries was originally an encapsulation error and remains a performance error, so there are Smalltalks that do not make that mistake. The *portable* way to make a Dictionary is (Dictionary new) at: k1 put: v1; ... at: kn put: vn; yourself. And why in the name of sanity are the keys *strings* instead of *symbols*? This is not Smalltalk. It is Javascript in drag. Now exercism.io has a habit of insisting on particular implementations. For example, I completed the SML track, and found that the test code ONLY worked with Poly and not with any of the three SML implementations I already had on my machine. Since you are doing this in Pharo, I take it that exercism.io will insist on the Smalltalk track being done in Pharo, and in that case it is *nauseating* to use a Dictionary when you could use a Point. Old-fashioned Smalltalk style would have been to return something like #(<direction> <x> <y>) e.g. #(north 1 0), and I still prefer that. In fact *good* Smalltalk style for something like this would be test11_MovesTheRobotForward1SpaceInTheDirectionItIsPointingIncreasesTheYCoordinateOneWhenFacingNorth robotSimulatorCalculator moveTo: 0@0; head: #north; obey: 'A'. self assert: robotSimulatorCalculator heading equals: #north. self assert: robotSimulatorCalculator location equals: 0@1. -- We're starting to get the idea that identifiers like robotSimulatorCalculator are not a very good idea when simulatedRobot would do the job as well or better. (This is also pointing us towards Betrand Meyer's Command/Query Separation principle, but we shan't go there today.) This is important feedback to give to the exercism.io people. The test code should use a SMALLTALK interface, not a warmed-over JAVASCRIPT interface. Now, how do we map between direction *names* and direction *points*? Well, we have to start by laying down clearly what we *mean* by the directions. To move North one step is to add 1 to y and 0 to x. (We know that from the appalling test case above.) To move South one step is to add -1 to y and 0 to x. (South is the opposite of North.) To move East one step, oh we have a problem. THIS NEEDS SPELLING OUT. And one of the things the exercism.io exercises are HORRIBLY BAD AT is specifying the problem. Nearly every single exercise I have tried, I have been unable to tell what the problem is without examining the test cases, and that is not the way exercises are supposed to work. (Yeah, that's why I'm screaming about it. I've taught a class using exercises like this that were not of my writing and vague specifications really upset the students. People who had taken the class under someone else several years before were still angry about it.) The geometric classes in Smalltalk were written to support graphic user interfaces. And in user interfaces, the y coordinate increases DOWN. So if we take the compass rose and rotate it so that North is DOWN, it follows that West is right and East is left. So To move East one step is to add -1 to x and 0 to y. To move West one step is to add 1 to x and 0 to y. The chances are excellent that the problem specification is inconsistent with this. Sigh. Let's proceed, though. North 0@1 South 0@ -1 East -1@0 West 1@0 pointToName: aPoint ^aPoint x isZero ifTrue: [aPoint y > 0 ifTrue: [#north] ifFalse: [#south]] ifFalse: [aPoint x > 0 ifTrue: [#west ] ifFalse: [#east ]] nameToPoint: aSymbol aSymbol = #north ifTrue: [^0 @ 1]. aSymbol = #south ifTrue: [^0 @ -1]. aSymbol = #west ifTrue: [^1 @ 0]. aSymbol = #east ifTrue: [^-1 @ 0]. aSymbol error: 'not a compass direction in lower case'. Another problem I had with exercism was a "Space-Age" exercise where the README.md capitalised the planet names but test_Space-Age.<whatever> insisted on lower case. That might well happen here. Just for grins, Dictionary>> asPoint ^(self at: 'x') @ (self at: 'y') Point>> asDictionary ^(Dictionary new) at: 'x' put: self x; at: 'y' put: self y; yourself On Mon, 8 Apr 2019 at 22:15, Roelof Wobben <r.wobben(a)home.nl> wrote: > Richard thanks. > > One thing I do not see direct. > > you said : > > > A direction could be represented by a pair of integers > dx, dy such that |dx|+|dy| = 1. It could also be > represented by a Point with integer components. > > for me a direction is the direction the robot is facing so something like > north or east. > > the challenge also wants a output like this : > > > test11_MovesTheRobotForward1SpaceInTheDirectionItIsPointingIncreasesTheYCoordinateOneWhenFacingNorth > | result | > result := robotSimulatorCalculator > moveDirection: 'north' > position: > (Dictionary new > add: 'x' -> 0; > add: 'y' -> 0; > yourself) > instructions: 'A'. > self > assert: result > equals: > (Dictionary new > add: 'direction' -> 'north'; > add: > 'position' > -> > (Dictionary new > add: 'x' -> 0; > add: 'y' -> 1; > yourself); > yourself) > > so how do I "convert" the point you are using to the text. > > Or do I misunderstood you somewhere wrong. > > Roelof > > > > > Op 8-4-2019 om 10:57 schreef Richard O'Keefe: > > One thing I have often seen and lamented is students > writing excessively complicated code with way too many > classes. There is a huge difference between > "A Robot knows its position and direction." > and > "A Robot has-a Position and has-a Direction." > The first is the important one. The second is > an over-commitment to too many classses. For a > problem like this, you really really do not want > a Direction class, and you certainly have no use > for double dispatch. > > A position can be represented by a pair of integers > x, y. It could also be represented by a Point with > integer components. > > A direction could be represented by a pair of integers > dx, dy such that |dx|+|dy| = 1. It could also be > represented by a Point with integer components. > > For movement, you need to be able to add the direction > to the location, which could be simply > x := x + dx. y := y + dy. > or it could be > position := position + direction. > For turning, you need to be able to rotate a direction > vector by ninety degrees. Now it so happens that > Point has methods #leftRotated and #rightRotated. > > So we can do the following: > a Robot has position (a Point) and direction (aPoint) > position := 0 @ 0. > direction := 0 @ 1. > To move forward without turning: > position := position + direction. > To turn left without moving: > direction := direction leftRotated. > To turn right without moving: > direction := direction rightRotated. > To obey a sequence of characters, commands: > commands do: [:each | > each caseOf: { > [$A] -> [--move forward--]. > [$L] -> [--turn left--]. > [$R] -> [--turn right--] > }]. > > > One of the key ideas in extreme programming is > "You Ain't Gonna Need It", abbreviated to YAGNI! > The idea is *DON'T* generalise beyond your immediate > needs. In this case, for example, the likelihood of > *this* program needing to deal with more general > kinds of movement is ZERO. And the only reason for > using Point here instead of just using a few simple > assignment statements is that Point already exists, > so costs nothing to write, and as a familiar class, > code using it should be easy to read. > > If someone challenges you to do something counter-productive, > refuse the challenge. > > On Mon, 8 Apr 2019 at 17:21, Roelof Wobben <r.wobben(a)home.nl> wrote: > >> I can try to explain what I trying to solve. >> >> I have a Robot which can turn left, turn right or moveForward. >> >> now I have a string like 'LAR' >> >> that means the robot needs to turn left (l) , move forward one place (A) >> and turn left. >> and I have to keep track to which direction the robot is facing and on >> which coordinate it stands. >> >> so to summarize with the above string >> >> lets say the robot is facing north on coordinate (0,0) >> then it has to turn left , so its facing east and still on coordinate >> (0,0) >> then it has to move forward, so its still facing east but are on >> coordinate(0,1) >> then it has to turn right, so its facing north and on coordinate (0,1) >> >> and TimMacKinnon has challenged me to do this with double dispatch. >> >> So I think now I need a object Direction, a sub object North and a sub - >> sub object TurnLeft, turnRight and moveForward. >> >> So I can use double dispath first the direction North, East, South, West >> and then use double dispatch to find the right move. >> >> Roelof >> >> >> >> >> >> Op 8-4-2019 om 06:50 schreef Richard O'Keefe: >> >> It would really REALLY **REALLY** help if we knew what >> the heck you were trying to do. There is an excellent >> chance that it is MUCH simpler than you think. If you >> cannot show us the Smalltalk version of the problem, >> can you show us the version for some other language? >> >> >> On Sun, 7 Apr 2019 at 20:15, Roelof Wobben <r.wobben(a)home.nl> wrote: >> >>> Op 6-4-2019 om 15:15 schreef K K Subbu: >>> > On 06/04/19 4:49 PM, Roelof Wobben wrote: >>> >> Hello, >>> >> >>> >> I just learned double dispatch. >>> >> And now for the Robot challenge of exercism Tim has pointed me to >>> >> this >>> >> article( >>> https://blog.metaobject.com/2019/04/accessors-have-message-obsession.html) >>> >>> >> >>> >> but I fail to see how the move method looks like in that article. >>> >> I had a conversation with Tim in the exercism channel and the way he >>> >> explains it, it looks like double dispatch for me. >>> >> >>> >> Am I on the right track or do I oversee something here. >>> > unary methods like moveRight perform specific ops and are not >>> > parametric, so only a single dispatch, depending on the receiver, is >>> > needed. >>> > >>> > If you change it to move: aDistanceOrAngle, then performing requests >>> > like "move: 3 cms" or "move: 30 degrees" will depend not only on the >>> > receiver but also on the class of the argument. This would need double >>> > dispatch (aka multiple polymorphism). The first dispatch would be >>> > based on the receiver and the receiver's method would then dispatch it >>> > based on the class of the argument (i.e. Distance>>move or Angle>>move >>> ) >>> > >>> > HTH .. Subbu >>> > >>> > >>> >>> >>> hmm, still stuck >>> >>> I have now a class Direction with as instance variables north, south, >>> east, west >>> and made the accessors. >>> >>> then I thought I need a initialize like this : >>> >>> initialize >>> north = Direction( 0, -1). >>> east = Direction( 1, 0). >>> south = Direction( 0, 1). >>> west = Direction(-1, 0). >>> >>> but the Direction (0,-1) is a problem . the compiler does not like the >>> (0,-1) part >>> >>> to give you the big picture. I have a Robot which can turnRight , >>> turnLeft and moveForward and I try to understand how the page would work >>> in my case. >>> >>> So I have a object Direction as described above and a Object MoveForward >>> which is a subobject of Direction. >>> MoveForward has only 1 method : >>> >>> IsMove >>> ^ 'A' >>> >>> Roelof >>> >>> >>> >> >

April 8, 2019

Re: [Pharo-users] How to catch and handle multiple exceptions

by Esteban Maringolo

Maybe the abstraction needed wraps everything within a single handler, but internally does a switch like statement dispatching to a particular error handler block. handledBlock exceptionDispatcher on: NotFoundError do: [:ex | ...]; on: MessageNotUnderstood do: [:ex | .. ]. BlockClosure>>exceptionDispatcher | exceptionDispatcher| exceptionDispatcher:= ExceptionDispatcher new. self on: Exception do: [:ex | dispatcher handle: ex ]. ^exceptionDispatcher ExceptionDispatcher>>on: exceptionClass do: aBlock self handlers add: exceptionClass -> aBlock The #exceptionDispatcher method would return this special object that deals with the resolution of each exception class (how to sort them would't be trivial unless done naively). But any resignalling would be only one level deep. Disclaimer: I just wrote the code as I replied this email, not guaranteed to work :) Esteban A. Maringolo El lun., 8 abr. 2019 a las 10:09, jtuchel(a)objektfabrik.de (<jtuchel(a)objektfabrik.de>) escribiÃ³: > > Am 08.04.19 um 14:39 schrieb Richard O'Keefe: > > >> > >> > It's easy enough to add your own methods like >> > on: exn1 do: act1 on: exn2 do: act2 >> > "An imperfect emulation of VAST's #when:do:when:do:" >> > ^[self on: exn1 do: act1] on: exn2 do: act2 >> > >> > on: exn1 do: act1 on: exn2 do: act2 on: exn3 do: act3 >> > "An imperfect emulation of VAST's #when:do:when:do:when:do:" >> > ^[[self on: exn1 do: act1] on: exn2 do: act2] on: exn3 do: act3 >> > to BlockClosure. It won't be fast, but your code might be >> > clearer. > > well, an unwanted side effect might be that the handling of exn1 is also guarded by the outer on:do: . > > Not that this has to be a problem but it introduces new things to think about when you want to #resignalAs: and such. > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > >

April 8, 2019

Re: [Pharo-users] How to catch and handle multiple exceptions

by jtuchel＠objektfabrik.de

Am 08.04.19 um 14:39 schrieb Richard O'Keefe: > > > > > It's easy enough to add your own methods like > > on: exn1 do: act1 on: exn2 do: act2 > >Â Â Â "An imperfect emulation of VAST's #when:do:when:do:" > >Â Â Â ^[self on: exn1 do: act1] on: exn2 do: act2 > > > > on: exn1 do: act1 on: exn2 do: act2 on: exn3 do: act3 > >Â Â Â "An imperfect emulation of VAST's #when:do:when:do:when:do:" > >Â Â Â ^[[self on: exn1 do: act1] on: exn2 do: act2] on: exn3 do: act3 > > to BlockClosure.Â It won't be fast, but your code might be > > clearer. > well, an unwanted side effect might be that the handling of exn1 is also guarded by the outer on:do: . Not that this has to be a problem but it introduces new things to think about when you want to #resignalAs: and such. -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

April 8, 2019

Re: [Pharo-users] How to catch and handle multiple exceptions

by Richard O'Keefe

It won't be fast because it creates multiple blocks, whereas a "native" version would not. To be honest I have not implemented exceptions in my Smalltalk yet, but I want to inline []on:do: constructions. The VAST system I have is 8.6.3, and it supports ANSI Exceptions. On Tue, 9 Apr 2019 at 00:31, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > Richard, > > I was going to comment the #when:do:[when:do:] approach of VAST [1]. > > Why do you say it won't be fast? Because of the multiple exception > handlers in the call stack? > > I think that some construct might be used to obtain the same as the > #when:do:when:do: but using a chained approach instead. > > Regards, > > [1] AFAIR when I used VAST (+a decade ago) it didn't have "ANSI" > exceptions. > > Esteban A. Maringolo > > El lun., 8 abr. 2019 a las 0:49, Richard O'Keefe (<raoknz(a)gmail.com>) > escribiÃ³: > > > > VisualAge Smalltalk has, in addition to the standard #on:do:, > > #when:do:, ..., #when:do:#when:do:#when:do:#when:do:#when:do:, > > with the last four mapping to #whenOneOf:doMatching:, taking > > two arrays. > > > > It's easy enough to add your own methods like > > on: exn1 do: act1 on: exn2 do: act2 > > "An imperfect emulation of VAST's #when:do:when:do:" > > ^[self on: exn1 do: act1] on: exn2 do: act2 > > > > on: exn1 do: act1 on: exn2 do: act2 on: exn3 do: act3 > > "An imperfect emulation of VAST's #when:do:when:do:when:do:" > > ^[[self on: exn1 do: act1] on: exn2 do: act2] on: exn3 do: act3 > > to BlockClosure. It won't be fast, but your code might be > > clearer. > > > > > > On Mon, 8 Apr 2019 at 10:21, Tim Mackinnon <tim(a)testit.works> wrote: > >> > >> > >> Thanks, I guess that makes sense, although it somehow looks a bit ugly > with the nested brackets.. but nothing else springs to mind so maybe Iâll > get used to it (and In my case I think itâs likely 2 or 3 different > exceptions) > >> > >> Tim > >> > >> Sent from my iPhone > >> > >> > On 7 Apr 2019, at 20:43, Richard Sargent < > richard.sargent(a)gemtalksystems.com> wrote: > >> > > >> > > >> > This last one. > >> > > >> > [[self run] > >> > on: TestFailure > >> > do: [:testEx | ...]] > >> > on: Error > >> > do: [:error | ...] > >> > >> > >

April 8, 2019

Re: [Pharo-users] How to catch and handle multiple exceptions

by Tim Mackinnon

Thanks Richard - indeed it was that VisualAge Smalltalk pattern that I was remembering and looking for in Pharo, and was a bit surprised it wasnât there - and hence thought thereâre was possibly a different way. I might propose we add this, if no-one else comes up with a better alternative. Handling both application and http exceptions is quite a common pattern - and you donât always want to do the same blanket thing. Tim Sent from my iPhone > On 8 Apr 2019, at 04:48, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > VisualAge Smalltalk has, in addition to the standard #on:do:, > #when:do:, ..., #when:do:#when:do:#when:do:#when:do:#when:do:, > with the last four mapping to #whenOneOf:doMatching:, taking > two arrays. > > It's easy enough to add your own methods like > on: exn1 do: act1 on: exn2 do: act2 > "An imperfect emulation of VAST's #when:do:when:do:" > ^[self on: exn1 do: act1] on: exn2 do: act2 > > on: exn1 do: act1 on: exn2 do: act2 on: exn3 do: act3 > "An imperfect emulation of VAST's #when:do:when:do:when:do:" > ^[[self on: exn1 do: act1] on: exn2 do: act2] on: exn3 do: act3 > to BlockClosure. It won't be fast, but your code might be > clearer. > > >> On Mon, 8 Apr 2019 at 10:21, Tim Mackinnon <tim(a)testit.works> wrote: >> >> Thanks, I guess that makes sense, although it somehow looks a bit ugly with the nested brackets.. but nothing else springs to mind so maybe Iâll get used to it (and In my case I think itâs likely 2 or 3 different exceptions) >> >> Tim >> >> Sent from my iPhone >> >> > On 7 Apr 2019, at 20:43, Richard Sargent <richard.sargent(a)gemtalksystems.com> wrote: >> > >> > >> > This last one. >> > >> > [[self run] >> > on: TestFailure >> > do: [:testEx | ...]] >> > on: Error >> > do: [:error | ...]

April 8, 2019