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

[Roelof Wobben]

  
  
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  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

[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  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] How to catch and handle multiple exceptions

[Richard O'Keefe]

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] How to catch and handle multiple exceptions

[Sean P. DeNigris]

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

[Sean P. DeNigris]

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

[Stephan Eggermont]

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]

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

[Richard Sargent]

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
>

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

[Tim Mackinnon]

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] Iceberg for files other than code?

[Tim Mackinnon]

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
> 

Re: [Pharo-users] Iceberg for files other than code?

[Konrad Hinsen]

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] difference between double dispatch and the method explains here

[Roelof Wobben]

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