- Pharo-users - lists.pharo.org

Re: [Pharo-users] how to model this a better way

by Ben Coman

On Mon, 22 Apr 2019 at 23:15, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > I already discoursed on this at some length. > (1) In my own answer, I used code to map direction names to vectors. > But the Dictionary answers are absolutely fine. > (2) I pointed out that there are ALREADY "turn left" and "turn right" > operations on Points. > (3) An elegant solution is one which wastes no effort. > Introducing classes that you don't need is definitely wasted > effort. Elegance in art is in the eye of the beholder. You've got one position on it. I'll just balance it with an alternative view for students to consider around "classes that you don't need". > WARNING: untested first draft code (can't find the tested stuff). > obey: commands > |position direction| > position := 0@0. > direction := 1@0. > commands do: [:each | > each caseOf: { > [$A] -> [position := position + direction]. > [$L] -> [direction := direction leftRotated]. > [$R] -> [direction := direction rightRotated] > }]. > ^{position. direction} > You will need to fiddle with this a bit to get the mapping between > problem coordinates and solution coordinates right, and you'll > need that Dictionary mapping directions to direction names, but > that's pretty much it. > If you define more than one class for this problem, your code is not elegant. If the purpose of the problems is simply to solve the problem, then doing the absolute minimum is a reasonable view of elegance. After all, its throw away code. You're never going to be maintaining it. But if the purpose of problems is to lead students in new ways of thinking about structuring OO solutions for maintainability within Pharo, then I feel its lacking. I remember an instructor from my youth advising that "practicing a kata poorly is the habit that will be reproduced automatically (in a crisis)" > ^{position. direction} For me, viewing {2@3. 1@0 } in a debugger is a much greater cognitive load than {2@3. 'Facing east'} to determine which direction its facing. So I consider the latter more elegant. TDD helps minimise class over-engineering, but for me the latter is a "need". In terms of throw-away exercises, its about what habits students want to gain from doing them. Just another perspective. cheers -ben

April 23, 2019

Re: [Pharo-users] Gettext

by Norbert Hartl

Just for the record. This is the repo we had before in the zweidenker repo. I transferred it to pharo-contributions. So if you use this repository you should update your metacello to reflect to new location. Any, thanks very much, Pavel, for taking the initiative. Gettext definitely needs some love and we didnât find time so far. Norbert > Am 23.04.2019 um 13:31 schrieb Pavel Krivanek <pavel.krivanek(a)gmail.com>: > > Hi, > > I made some little tweaks on the Gettext project and I wrote few lines of documentation about it: > > https://github.com/pharo-contributions/Gettext <https://github.com/pharo-contributions/Gettext> > > Feel free to contribute if it may be interesting for your applications. Notice that I am not the original author of this project, I'm just passing by ;-) > > Cheers, > -- Pavel >

April 23, 2019

Re: [Pharo-users] Revisiting the inheritance of tests in 2019....

by Sven Van Caekenberghe

> On 23 Apr 2019, at 13:47, Tim Mackinnon <tim(a)testit.works> wrote: > > I you refactor some common tests and push them up to a superclass - e.g. (ProjectTestCase) > > TestCase > + ProjectTestCase > Domain1Test > Domain2Test > > > The tests you push up into ProjectTestCase wonât be run (like you would expect with a normal object using normal inheritance). You have to define a method #shouldInheritSelectors, which is quite subtle, and if you're not careful you wonât realise you arenât running those tests. And if you later refactor again, you may silently break something. Wow, I have been using inheritance in Unit Tests quite a lot (e.g. STONWriteReadTests) and I knew about #isAbstract but not about #shouldInheritSelectors Looking at the standard implementation of #shouldInheritSelectors (which is quite complex, never a good sign), I get a feeling why it never hurt me, but still, this is indeed surprising and thus not good. > Its an easy trap to fall into (like myself and colleague did). While Iâm sure there was some rational when this was done many years ago, Iâm just not sure it holds today (or if the full implications were realised). Like Cyril, several years ago - it just caught me out. > > A simple solution would be to have PharoTestCase - that works like normal objects, and our tools to create an initial test could just subclass it. TestCase can stay for compatibility? > > Anything we can do to make testing easier and safe has got to be a good thing? While I donât like to propose diverging, it seems that the status quo will just prevail and future developers will make this same preventable mistake. > > Tim > >> On 23 Apr 2019, at 13:14, Tim Mackinnon <tim(a)testit.works> wrote: >> >> I just got burned by tests not inheriting from a TestCase superclassâ¦ I note that in 2017, Cyril tried to argue to get this changed to work just like normal objects (proposing that for P7 tests works like any other objectâ¦) but I think it was just too difficult to argue against a decision made so long ago. >> >> I tried to follow the 2017 logic about why you would want tests to operate differently than other objects, but I couldnât understand it. I did see that some numbers run against Squeak Trunk argued that it was fine â¦. but Iâm left wondering about all the people with individual projects like me that just expect objects to behave like objects and not have unexpected behaviour. Deviating seems like extra complexity that Iâd prefer not to have to worry about. >> >> Given Pharo is revisiting the concept of testing (with Dr Test) - could we possibly introduce the normal object behaviour somehow? Possibly we could have a new superclass for Tests - and use it to move forward without breaking existing stuff and those who want to stick with this other way of thinking? >> >> >> Tim >> >> >> > >

April 23, 2019

Re: [Pharo-users] Revisiting the inheritance of tests in 2019....

by Tim Mackinnon

I you refactor some common tests and push them up to a superclass - e.g. (ProjectTestCase) TestCase + ProjectTestCase Domain1Test Domain2Test The tests you push up into ProjectTestCase wonât be run (like you would expect with a normal object using normal inheritance). You have to define a method #shouldInheritSelectors, which is quite subtle, and if you're not careful you wonât realise you arenât running those tests. And if you later refactor again, you may silently break something. Its an easy trap to fall into (like myself and colleague did). While Iâm sure there was some rational when this was done many years ago, Iâm just not sure it holds today (or if the full implications were realised). Like Cyril, several years ago - it just caught me out. A simple solution would be to have PharoTestCase - that works like normal objects, and our tools to create an initial test could just subclass it. TestCase can stay for compatibility? Anything we can do to make testing easier and safe has got to be a good thing? While I donât like to propose diverging, it seems that the status quo will just prevail and future developers will make this same preventable mistake. Tim > On 23 Apr 2019, at 13:14, Tim Mackinnon <tim(a)testit.works> wrote: > > I just got burned by tests not inheriting from a TestCase superclassâ¦ I note that in 2017, Cyril tried to argue to get this changed to work just like normal objects (proposing that for P7 tests works like any other objectâ¦) but I think it was just too difficult to argue against a decision made so long ago. > > I tried to follow the 2017 logic about why you would want tests to operate differently than other objects, but I couldnât understand it. I did see that some numbers run against Squeak Trunk argued that it was fine â¦. but Iâm left wondering about all the people with individual projects like me that just expect objects to behave like objects and not have unexpected behaviour. Deviating seems like extra complexity that Iâd prefer not to have to worry about. > > Given Pharo is revisiting the concept of testing (with Dr Test) - could we possibly introduce the normal object behaviour somehow? Possibly we could have a new superclass for Tests - and use it to move forward without breaking existing stuff and those who want to stick with this other way of thinking? > > > Tim > > >

April 23, 2019

Gettext

by Pavel Krivanek

Hi, I made some little tweaks on the Gettext project and I wrote few lines of documentation about it: https://github.com/pharo-contributions/Gettext Feel free to contribute if it may be interesting for your applications. Notice that I am not the original author of this project, I'm just passing by ;-) Cheers, -- Pavel

April 23, 2019

Re: [Pharo-users] Revisiting the inheritance of tests in 2019....

by Sven Van Caekenberghe

What do you suggest ? Right now, a unit test has to inherit from TestCase, seems quite logical to me. You want any object to be able to contain unit tests ? How do you want to mark them ? With a pragma ? What if I forget the pragma ? ;-) IOW, what exactly is the problem ? > On 23 Apr 2019, at 13:14, Tim Mackinnon <tim(a)testit.works> wrote: > > I just got burned by tests not inheriting from a TestCase superclassâ¦ I note that in 2017, Cyril tried to argue to get this changed to work just like normal objects (proposing that for P7 tests works like any other objectâ¦) but I think it was just too difficult to argue against a decision made so long ago. > > I tried to follow the 2017 logic about why you would want tests to operate differently than other objects, but I couldnât understand it. I did see that some numbers run against Squeak Trunk argued that it was fine â¦. but Iâm left wondering about all the people with individual projects like me that just expect objects to behave like objects and not have unexpected behaviour. Deviating seems like extra complexity that Iâd prefer not to have to worry about. > > Given Pharo is revisiting the concept of testing (with Dr Test) - could we possibly introduce the normal object behaviour somehow? Possibly we could have a new superclass for Tests - and use it to move forward without breaking existing stuff and those who want to stick with this other way of thinking? > > > Tim > > >

April 23, 2019

Revisiting the inheritance of tests in 2019....

by Tim Mackinnon

I just got burned by tests not inheriting from a TestCase superclassâ¦ I note that in 2017, Cyril tried to argue to get this changed to work just like normal objects (proposing that for P7 tests works like any other objectâ¦) but I think it was just too difficult to argue against a decision made so long ago. I tried to follow the 2017 logic about why you would want tests to operate differently than other objects, but I couldnât understand it. I did see that some numbers run against Squeak Trunk argued that it was fine â¦. but Iâm left wondering about all the people with individual projects like me that just expect objects to behave like objects and not have unexpected behaviour. Deviating seems like extra complexity that Iâd prefer not to have to worry about. Given Pharo is revisiting the concept of testing (with Dr Test) - could we possibly introduce the normal object behaviour somehow? Possibly we could have a new superclass for Tests - and use it to move forward without breaking existing stuff and those who want to stick with this other way of thinking? Tim

April 23, 2019

Re: [Pharo-users] A4BP and BpmFlow

by BrunoBB

Serge, I just read the PDF but i will need time to learn about other Workflow projects. But definitely in the long term we can collaborate but now i do not see any concrete step (because my lack of knowledge of the other projects). Maybe the more concrete step to do now is to ask how each project solved different BPM problems. So each project can benefit from the others experience. Not sure if a mail list is the best tool or we should create a Git wiki or something like that. It seems there at least 4 Smalltalk project working with workflows - good news ! regards bruno -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 22, 2019

Re: [Pharo-users] [ANN| Moved ImageWorker to smalltalkhub

by Mariano Martinez Peck

On Mon, Apr 22, 2019 at 5:36 AM Norbert Hartl <norbert(a)hartl.name> wrote: > I migrated the source of ImageWorker from smalltalkhub to github > > https://github.com/pharo-contributions/ImageWorker > > Now Iâm changing voyage to use the github ImageWorker. > > FYI, > > Norbert > OK... so then to email subject s/to/from Anyway, thanks for doing that! -- Mariano Martinez Peck Email: marianopeck(a)gmail.com Twitter: @MartinezPeck LinkedIn: https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/

April 22, 2019

Re: [Pharo-users] how to model this a better way

by Richard O'Keefe

I already discoursed on this at some length. (1) In my own answer, I used code to map direction names to vectors. But the Dictionary answers are absolutely fine. (2) I pointed out that there are ALREADY "turn left" and "turn right" operations on Points. (3) An elegant solution is one which wastes no effort. Introducing classes that you don't need is definitely wasted effort. WARNING: untested first draft code (can't find the tested stuff). obey: commands |position direction| position := 0@0. direction := 1@0. commands do: [:each | each caseOf: { [$A] -> [position := position + direction]. [$L] -> [direction := direction leftRotated]. [$R] -> [direction := direction rightRotated] }]. ^{position. direction} You will need to fiddle with this a bit to get the mapping between problem coordinates and solution coordinates right, and you'll need that Dictionary mapping directions to direction names, but that's pretty much it. If you define more than one class for this problem, your code is not elegant. On Fri, 19 Apr 2019 at 08:05, Tim Mackinnon <tim(a)testit.works> wrote: > You quickly find itâs a more interesting exercise than just a âpoint and > dictionaryâ, particularly if you want to do it in an elegant Smalltalk way > (but not over do it either). > > The interesting bit is that when facing a new direction, you need to know > how to advance in that direction , and also what âleftâ and ârightâ of that > direction are too. So it teases out having some objects and techniques for > this. > > For those interested - join exercism-Pharo ( > https://exercism.io/tracks/pharo-smalltalk/installation) in non mentor > mode and you can easily download it with the tests and try it out yourself > (without running through the other exercises). > > Tim > > Sent from my iPhone > > On 18 Apr 2019, at 21:41, Richard Sargent < > richard.sargent(a)gemtalksystems.com> wrote: > > Your system would have instance variables holding the cardinal directions > and another holding the current direction vector. > e.g. > north := DirectionVector x: 0 y: 1 name: 'north'. > > Your robot would implement e.g. #faceNorth to assign the "north" direction > vector to the current direction vector instance variable. > > > > On Thu, Apr 18, 2019 at 12:17 PM Roelof Wobben <r.wobben(a)home.nl> wrote: > >> oke, and how must I see those classes and elemating the need for a lookup. >> >> it may be explained in pseudo-code. >> >> Roelof >> >> >> >> Op 18-4-2019 om 20:28 schreef Richard Sargent: >> >> On Thu, Apr 18, 2019 at 10:33 AM Roelof Wobben <r.wobben(a)home.nl> wrote: >> >>> oke >>> >>> Maybe I understand something not right, >>> >>> Lets say we have this scenario. >>> >>> Robot is on position (0,0) >>> now it turns left so the robot faces East >>> >> >> I don't understand what position has to do with direction nor why that >> would be a problem. They are two distinct attributes. >> Point and Dictionary are sufficient classes to model the limited >> requirements of this exercise. >> You could model a new class DirectionVector which internalizes the Point >> used to provide the direction and provides its own name, eliminating the >> need for a look up of any kind. >> >> >>> or this scenario >>> >>> Robot is on position (0,0) >>> now it turns right so the robot faces west. >>> >>> it looks that dictionary cannot provide this answer. >>> or do I overlook something >>> >>> Roelof >>> >>> >>> >>> Op 18-4-2019 om 19:17 schreef Richard Sargent: >>> >>> On Thu, Apr 18, 2019 at 10:01 AM Roelof Wobben <r.wobben(a)home.nl> wrote: >>> >>>> yep, I have read that one >>>> but I never gets a answer how I can "convert" a point to something >>>> like north, east >>>> >>>> because the challenge wants this to be the answer : >>>> >>>> (Dictionary new >>>> add: 'direction' -> 'north'; >>>> add: >>>> 'position' >>>> -> >>>> (Dictionary new >>>> add: 'x' -> 0; >>>> add: 'y' -> 0; >>>> yourself); >>>> yourself) >>>> >>> >>> If you have previously defined a "representation map", you would be >>> golden. >>> >>> e.g. >>> Dictionary new >>> at: self northDirectionVector put: 'north'; >>> at: self eastDirectionVector put: 'east'; >>> at: self southDirectionVector put: 'south'; >>> at: self westDirectionVector put: 'west'; >>> yourself. >>> >>> Then: >>> (Dictionary new >>> add: 'direction' -> (self directionRepresentationMap at: >>> self directionVector); >>> ... >>> >>> >>>> >>>> and I think I need then to use if then , which I try to avoid as much >>>> as possible. >>>> >>>> Roelof >>>> >>>> >>>> >>>> Op 18-4-2019 om 18:33 schreef Richard Sargent: >>>> >>>> On Thu, Apr 18, 2019 at 8:57 AM Roelof Wobben <r.wobben(a)home.nl> wrote: >>>> >>>>> Hello, >>>>> >>>>> I know I have asked earlier but im still stuck on this one : >>>>> https://github.com/exercism/problem-specifications/blob/master/exercises/ro… >>>>> >>>>> I tried with all double dispatch but that will be a lot of duplicate >>>>> classes >>>>> >>>>> The problem I cannot solve right is that a robot can move or turn. >>>>> when a robot turns only the direction the robot is facing changes and the >>>>> position not. when a robot moves the facing direction stays the same but >>>>> the position changes. but the change is dependend on the facing. Also the >>>>> new facing direction is dependend on the old facing direction/ >>>>> How can I model this the best. >>>>> >>>>> I already have a object Robot that contains the facing direction and >>>>> the current position >>>>> or tried without it but then I use a lot of if then's >>>>> >>>>> >>>>> so it there a better way to model this problem so it will be all >>>>> nice and readable code. >>>>> >>>> >>>> If I remember correctly, Richard O'Keefe gave you a viable design. 1) >>>> Use a Point for your direction vector. 2) Use a second Point for your >>>> position. >>>> >>>> e.g. if you align the compass with a Cartesian plane, 0@1 is North, 0@-1 >>>> is South, 1@0 is East, and -1@0 is West. When you move, you add the >>>> direction vector to your current position. If you allow movements of >>>> greater than a single unit, you multiply the direction vector by the >>>> distance before adding that product to the position. >>>> >>>> >>>>> Roelof >>>>> >>>>> >>>> >>> >>

April 22, 2019