Re: [Pharo-users] difference between double dispatch and the method explains here
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
Re: [Pharo-users] Iceberg for files other than code?
Hi Christopher and Tim, Thanks for your comments! I agree that managing the README from Pharo is not the most important use case, I just mentioned it because everyone know what a README is. A better example of what I want to do is Pharo's Help system. It stores the individual pages as methods that return a literal string. That's one way to store data in a package but it looks like a kludge. More importantly, it is very difficult to use or edit the pages outside of Pharo. A better way to do something like that is to store pages as plain text in the same repository as the classes that use them. But that requires that the class can access the files as "file xx/yy/zz.txt in the same repository from which my code was loaded". And if the class modifies the text file, that change must be committed somehow. I suspect that the read access part is doable somehow. The repository checkout in pharo-local contains all the files, so it's just a matter of figuring out the path. It's committing changes that requires some support from Iceberg, which you says is not available if I understand correctly. Konrad
Re: [Pharo-users] Iceberg for files other than code?
Hi Konrad - I think you can do what you describe - I think the ICeRepository entry for your project will have the path you want. And yes, its the committing back non source files where iceberg doesn’t try to do anything (and so needs help from elsewhere). Tim > On 7 Apr 2019, at 16:40, Konrad Hinsen wrote: > > Hi Christopher and Tim, > > Thanks for your comments! > > I agree that managing the README from Pharo is not the most important > use case, I just mentioned it because everyone know what a README is. > > A better example of what I want to do is Pharo's Help system. It stores > the individual pages as methods that return a literal string. That's one > way to store data in a package but it looks like a kludge. More > importantly, it is very difficult to use or edit the pages outside of > Pharo. > > A better way to do something like that is to store pages as plain text > in the same repository as the classes that use them. But that requires > that the class can access the files as "file xx/yy/zz.txt in the same > repository from which my code was loaded". And if the class modifies the > text file, that change must be committed somehow. > > I suspect that the read access part is doable somehow. The repository > checkout in pharo-local contains all the files, so it's just a matter of > figuring out the path. It's committing changes that requires some > support from Iceberg, which you says is not available if I understand > correctly. > > Konrad >
[Pharo-users] How to catch and handle multiple exceptions
Hi - I’m wondering what the best way for handling multiple exceptions is in Pharo? It seems like we just have on:do: (where on is a single exception?). However, I think I’ve noticed that you can concatenate exceptions - so DomainError, ZnHttpUnsuccessful - and then pass that to on: However, I’m not clear on how we then elegantly process the exception if you want to do different things (which is often the case for unrelated exceptions). I am kind of superseded there isn’t on:do:on:do: (although that seems quite ugly). So I’m curious how you handle different exceptions without having some sort of case statement in the exception handler? Or do you wrap exceptions handlers over top of each other? Tim
Re: [Pharo-users] How to catch and handle multiple exceptions
On Sun, Apr 7, 2019, 12:13 Tim Mackinnon wrote: > Hi - I’m wondering what the best way for handling multiple exceptions is > in Pharo? > > It seems like we just have on:do: (where on is a single exception?). > > However, I think I’ve noticed that you can concatenate exceptions - so > DomainError, ZnHttpUnsuccessful - and then pass that to on: > > However, I’m not clear on how we then elegantly process the exception if > you want to do different things (which is often the case for unrelated > exceptions). I am kind of superseded there isn’t on:do:on:do: (although > that seems quite ugly). > > So I’m curious how you handle different exceptions without having some > sort of case statement in the exception handler? Or do you wrap exceptions > handlers over top of each other? > This last one. [[self run] on: TestFailure do: [:testEx | ...]] on: Error do: [:error | ...] > Tim >
Re: [Pharo-users] How to catch and handle multiple exceptions
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 > wrote: > > > This last one. > > [[self run] > on: TestFailure > do: [:testEx | ...]] > on: Error > do: [:error | ...]
Re: [Pharo-users] How to catch and handle multiple exceptions
Tim Mackinnon 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) I think I prefer them to be somehow ugly. I don’t want to encourage you to nest and chain exceptions 😀 Stephan
Re: [Pharo-users] How to catch and handle multiple exceptions
Tim Mackinnon wrote > nothing else springs to mind Double dispatch w extension methods on the Exception classes? - Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Re: [Pharo-users] How to catch and handle multiple exceptions
Or I guess you don't even need dd here, just #handleMyErrorCase polymorphically - Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Re: [Pharo-users] How to catch and handle multiple exceptions
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 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.sarg...@gemtalksystems.com> wrote: > > > > > > This last one. > > > > [[self run] > > on: TestFailure > > do: [:testEx | ...]] > > on: Error > > do: [:error | ...] > > >
Re: [Pharo-users] difference between double dispatch and the method explains here
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 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 > > >
Re: [Pharo-users] difference between double dispatch and the method explains here
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 Wobbenwrote: 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