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 <http://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 <http://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
<http://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 <http://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.wob...@home.nl <mailto:r.wob...@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.wob...@home.nl <mailto:r.wob...@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.wob...@home.nl <mailto:r.wob...@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
