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

[Ben Coman]

On Fri, 19 Apr 2019 at 01:33, Roelof Wobben  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 think the required method was mentioned previously, but here is how
to discover it yourself...

+ Tool > Finder > Examples
+ Enter...(0@1) . (1@0) 

finds...  Point>>leftRotated
e.g. (0@1) leftRotated   ==>   (1@0)

On Fri, 19 Apr 2019 at 01:39, Roelof Wobben  wrote:
>
> Ben,
>
> I have such a dictionary in my first attempt to solve this one.
> and another one for the facing.

This sounds strange that you have two Dictionaries.
It can be useful to encapsulate the mapping to avoid that being
littered around your Robot code...

Object subclass: #Facing
instanceVariables: 'map directionVector'

Facing >> initialize
map := Dictionary newFromPairs: {
'north'. (0@1) .
'west' . (0@1) leftRotated .
'south'. (0@1) leftRotated leftRotated.
'east' . (0@1) rightRotated }.
   directionVector := map atRandom.

Facing >> directionString
 ^ map keyAtValue: directionVector

Facing >> printOn: aStream
" Facing new inspect "
aStream nextPutAll: self className, '-', self directionString

"The above is produces a minimum-viable object that displays nicely in Inspector
to facilitate incrementally coding your scenario in TDD way..."

> Lets say we have this scenario:

TestCase subclass: FacingTest

FacingTest>>testAllTogether
   |position facing|

   "Robot begins at (0,0) facing north"
   position := 0@0.
   facing := Facing new face: 'north'.
   self assert: facing printString equals: 'Facing-north'.

   "then it turns right so it faces >>EAST<<"
   facing turnRight.
   self assert: facing printString equals: 'Facing-east'.

"then it moves one step so the new position is (-1,0)"
position := position + (facing movementSteps: 1).
self assert: position equals: (-1@0).

"then it turns left so it faces north again"
   facing turnLeft.
   self assert: facing printString equals: 'Facing-north'.

"then it moves one step so the new position is (-1,1)"
position := position + (facing movementSteps: 1).
self assert: position equals: (-1@1).


Which I'll leave as an exercise for you to complete with these hints...

Facing >> face: aDirectionString
   directionVector := ...

Facing >> turnRight
directionVector := ...

Facing >> turnLeft
directionVector := ...

Facing >> movementSteps: steps
^ ...


> so if I see it , the position has nothing to do with the direction the
> robot is facing

yes. they only interact when the robot moves


> this [position] is only important for finding out a new direction

no - position has no impact for determining the new direction


> or to find out if the x or the y needs to change.

You don't need to treat x and y separately.
Using Points for both the "position" and "directionVector" facilitates
simple addition.

cheers -ben


>
> Roelof
>
>
>
> Op 18-4-2019 om 19:17 schreef Richard Sargent:
>
> On Thu, Apr 18, 2019 at 10:01 AM Roelof Wobben  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  wrote:
>>>
>>> Hello,
>>>
>>> I know I have asked earlier but im still stuck on this one : 
>>> https://github.com/exercism/problem-specifications/blob/master/exercises/robot-simulator/description.md
>>>
>>> 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 

Re: [Pharo-users] Why are package tags not proper sub-packages?

[Sean P. DeNigris]

Ben Coman wrote
>> The implication here is that extension methods can’t live on the tag
>> (they
>> live on the parent package

Won't that cause existing code not designed with that restriction in mind to
be lost on save?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

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

[Tim Mackinnon]

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 
>  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  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  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  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  wrote:
 Hello, 
 
 I know I have asked earlier but im still stuck on this one : 
 https://github.com/exercism/problem-specifications/blob/master/exercises/robot-simulator/description.md
 
 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 

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

[Richard Sargent]

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  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  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  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  wrote:
>>>
 Hello,

 I know I have asked earlier but im still stuck on this one :
 https://github.com/exercism/problem-specifications/blob/master/exercises/robot-simulator/description.md

 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


>>>
>>
>

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

[Roelof Wobben]

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

wrote:
  
  

  Hello,

   

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

[Roelof Wobben]

Ben,

I have such a dictionary in my first attempt to solve this one.
and another one for the facing.


Lets say we have this scenario:

Robot begins at (0,0) facing north
then it turns right so it faces west
then it moves one step so the new position is (-1,0)
then it turns left so it faces north again
then it moves one step so the  new position is (-1,1)

so if I see it , the position has nothing to do with the direction the 
robot is facing
this is only important for finding out a new direction or  to find out 
if the x or the y needs to change.


Roelof



Op 18-4-2019 om 19:27 schreef Ben Coman:

map := Dictionary newFromPairs: {
 'north'.  0 @  1 .
 'south'.  0 @ -1 .
 'east'.   1 @  0 .
 'west' . -1 @  0 }.
 (map at: 'north') inspect.
 (map keyAtValue: 0 @ -1) inspect

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

[Roelof Wobben]

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


  
Hello,
  
  
  I know I have asked earlier but im still stuck
  on this one : https://github.com/exercism/problem-specifications/blob/master/exercises/robot-simulator/description.md
  


  

  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

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

[Ben Coman]

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

On Fri, 19 Apr 2019 at 01:01, Roelof Wobben  wrote:
>
> yep, I have read that one
> but I never gets a answer how I can "convert"  a point to something like 
> north, east

Maybe you are looking for something like this...
map := Dictionary newFromPairs: {
'north'.  0 @  1 .
'south'.  0 @ -1 .
'east'.   1 @  0 .
'west' . -1 @  0 }.
(map at: 'north') inspect.
(map keyAtValue: 0 @ -1) inspect.

cheers -ben

>
> 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)
>
>
> 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  wrote:
>>
>> Hello,
>>
>> I know I have asked earlier but im still stuck on this one : 
>> https://github.com/exercism/problem-specifications/blob/master/exercises/robot-simulator/description.md
>>
>> 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
>>
>

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

[Richard Sargent]

On Thu, Apr 18, 2019 at 10:01 AM Roelof Wobben  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  wrote:
>
>> Hello,
>>
>> I know I have asked earlier but im still stuck on this one :
>> https://github.com/exercism/problem-specifications/blob/master/exercises/robot-simulator/description.md
>>
>> 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
>>
>>
>

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

[Roelof Wobben]

  
  
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)
  
  
  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  wrote:
  
  

  Hello,


I know I have asked earlier but im still stuck on this
one : https://github.com/exercism/problem-specifications/blob/master/exercises/robot-simulator/description.md

  
  

  
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
  

  

  


  

Re: [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

[Ronie Salgado]

That looks very cool

For the text editor are you using GtkSourceView or something else?

Greetings,
Ronie

El jue., 18 abr. 2019 a las 7:23, Esteban Lorenzano ()
escribió:

>
>
> On 18 Apr 2019, at 13:08, PBKResearch  wrote:
>
> +1 to Norbert. In particular, does it mean that, from Pharo 8, we will be
> *required* to install Gtk3 backend to use Pharo?
>
>
> For now is in early development so there is no easy way to install (since
> there are things to replace/fix in current image).
> We will provide an install script soon (or maybe a prepared image, while
> we arrive to have a reliable baseline).
>
> And no, you will not need it. Gtk3 bindings are an extra. If you want to
> do a desktop application (for example Schmidt is doing it), maybe you will
> want to install it. Otherwise you will continue as before.
>
> And to be clear: Pharo 8 WILL NOT be a Gtk3 application.
> Even if eventually the IDE will be able to run with it (since it will be a
> Spec 2.0 based IDE), there are a lot of huge things that need to be
> migrated before (and the GTInspector is not big: Calypso is).
> And still then (maybe in Pharo 9), running with Gtk3 will be a choice.
>
> Esteban
>
>
> Peter Kenny
>
> *From:* Pharo-users  *On Behalf Of 
> *Norbert
> Hartl
> *Sent:* 18 April 2019 11:58
> *To:* Pharo users users 
> *Cc:* Pharo Dev 
> *Subject:* Re: [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3
> bindings)
>
> Great!
>
> Can you explain what is there, what somebody can load and what to expect.
> And even more important: what not to expect?
>
> I don’t get any of the essential details from this mail.
>
> Norbert
>
>
>
>
> Am 18.04.2019 um 12:08 schrieb Esteban Lorenzano :
>
> People that assisted to Pharo Days 2019 (or that follow my twitter
> account) already know this, but it needs to be formally announced:
>
>
> *We are working on Spec 2.0, and it will provide not just the classic
> Morphic bindings but also a new option for developers: Gtk3 bindings!*
>
> Why we want a Spec 2.0 with different backends?
>
> There are reasons that converged to decide us to make it:
>
>
>- First, to provide a validated abstract Spec 2.0 that can be used
>with different backends, preparing Pharo to be able to switch backends
>without needing to recreate the full IDE from scratch each time (a problem
>we have partially now in our way to deprecate Morphic).
>- Second, because we receive from different sources the requirement of
>having the possibility of developing real native-looking desktop
>applications. Yes, in moment where people talk about the cloud, SaaS and
>web-applications as the "next big thing" (something that is been declared
>since years, by the way), we believe is important to provide this, for two
>big reasons:
>
>
>1. Because there is still an important place for desktop applications
>   market and most medium-size to big business still require them.
>   2. Because Pharo itself is a desktop application! (And we need to
>   provide the best experience possible on it).
>
>
> For us, this is a fundamental step to continue improving Pharo itself, and
> it matches also the work we are doing on going real-headless:  Pharo users
> will be able to start the Morphic world, a Gtk application or the next
> backend to come.
>
> Why Gtk3?
>
> There are some other important players in the "native widgets scene", so
> why we choose Gtk3?
>
> Again, several reasons  were taken into account:
>
>
>- Gtk3 is cross platform. Yes, technically is just "native" in linux,
>but it works on Windows and macOS too.
>- It is very mature and popular.
>- It is made in plain C.
>
>
> Next step: tool migration
>
> The only way to know if you have covered what is needed is actually taking
> real-life use cases and implementing them. We have a list of tools that
> needs to be migrated and we are starting from them:
>
>
>1. Old GT tools will be replaced by new Spec tools (while preserving
>its power).
>2. Calypso UI needs to be rewritten in Spec 2.0 (it is in plain
>Morphic now).
>3. Pharo launcher as a standalone application is a good example of
>what you can do with the Gtk3 bindings.
>
>
> And that's it. Pharo 8.0 will come with Spec 2.0 and users will be able to
> benefit of it immediately :)
>
>
> A small screenshot of the new Inspector (WIP):
>
> 
>
> Esteban
>
>
>

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

[Richard Sargent]

On Thu, Apr 18, 2019 at 8:57 AM Roelof Wobben  wrote:

> Hello,
>
> I know I have asked earlier but im still stuck on this one :
> https://github.com/exercism/problem-specifications/blob/master/exercises/robot-simulator/description.md
>
> 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
>
>

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

[Roelof Wobben]

  
  
Hello, 
  
  I know I have asked earlier but im still stuck on this one : https://github.com/exercism/problem-specifications/blob/master/exercises/robot-simulator/description.md
  


  

  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. 

Roelof

  

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[Stephan Eggermont]

TedVanGaalen  wrote:
> ok, I'll try 
> please give me a link to that VM  20182039
> can't find it here:
> https://files.pharo.org/vm/pharo-spur64/

Sorry, that’s a typo. See the issue

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[TedVanGaalen]

ok, I'll try 
please give me a link to that VM  20182039
can't find it here:
https://files.pharo.org/vm/pharo-spur64/mac/

TedvG



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

[Esteban Lorenzano]

> On 18 Apr 2019, at 13:08, PBKResearch  wrote:
> 
> +1 to Norbert. In particular, does it mean that, from Pharo 8, we will be 
> *required* to install Gtk3 backend to use Pharo?

For now is in early development so there is no easy way to install (since there 
are things to replace/fix in current image). 
We will provide an install script soon (or maybe a prepared image, while we 
arrive to have a reliable baseline).

And no, you will not need it. Gtk3 bindings are an extra. If you want to do a 
desktop application (for example Schmidt is doing it), maybe you will want to 
install it. Otherwise you will continue as before.

And to be clear: Pharo 8 WILL NOT be a Gtk3 application. 
Even if eventually the IDE will be able to run with it (since it will be a Spec 
2.0 based IDE), there are a lot of huge things that need to be migrated before 
(and the GTInspector is not big: Calypso is).
And still then (maybe in Pharo 9), running with Gtk3 will be a choice.

Esteban

>  
> Peter Kenny
>  
> From: Pharo-users  On Behalf Of Norbert 
> Hartl
> Sent: 18 April 2019 11:58
> To: Pharo users users 
> Cc: Pharo Dev 
> Subject: Re: [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)
>  
> Great!
>  
> Can you explain what is there, what somebody can load and what to expect. And 
> even more important: what not to expect?
>  
> I don’t get any of the essential details from this mail.
>  
> Norbert
>  
>  
> 
>> Am 18.04.2019 um 12:08 schrieb Esteban Lorenzano > >:
>>  
>> People that assisted to Pharo Days 2019 (or that follow my twitter account) 
>> already know this, but it needs to be formally announced: 
>>  
>> 
>> We are working on Spec 2.0, and it will provide not just the classic Morphic 
>> bindings but also a new option for developers: Gtk3 bindings!
>>  
>> Why we want a Spec 2.0 with different backends?
>>  
>> There are reasons that converged to decide us to make it:
>>  
>> First, to provide a validated abstract Spec 2.0 that can be used with 
>> different backends, preparing Pharo to be able to switch backends without 
>> needing to recreate the full IDE from scratch each time (a problem we have 
>> partially now in our way to deprecate Morphic).
>> Second, because we receive from different sources the requirement of having 
>> the possibility of developing real native-looking desktop applications. Yes, 
>> in moment where people talk about the cloud, SaaS and web-applications as 
>> the "next big thing" (something that is been declared since years, by the 
>> way), we believe is important to provide this, for two big reasons: 
>> Because there is still an important place for desktop applications market 
>> and most medium-size to big business still require them.
>> Because Pharo itself is a desktop application! (And we need to provide the 
>> best experience possible on it).
>>  
>> For us, this is a fundamental step to continue improving Pharo itself, and 
>> it matches also the work we are doing on going real-headless:  Pharo users 
>> will be able to start the Morphic world, a Gtk application or the next 
>> backend to come.
>>  
>> Why Gtk3?
>>  
>> There are some other important players in the "native widgets scene", so why 
>> we choose Gtk3? 
>>  
>> Again, several reasons  were taken into account: 
>>  
>> Gtk3 is cross platform. Yes, technically is just "native" in linux, but it 
>> works on Windows and macOS too. 
>> It is very mature and popular.
>> It is made in plain C.
>>  
>> Next step: tool migration
>>  
>> The only way to know if you have covered what is needed is actually taking 
>> real-life use cases and implementing them. We have a list of tools that 
>> needs to be migrated and we are starting from them: 
>>  
>> Old GT tools will be replaced by new Spec tools (while preserving its power).
>> Calypso UI needs to be rewritten in Spec 2.0 (it is in plain Morphic now).
>> Pharo launcher as a standalone application is a good example of what you can 
>> do with the Gtk3 bindings.
>>  
>> And that's it. Pharo 8.0 will come with Spec 2.0 and users will be able to 
>> benefit of it immediately :)
>>  
>>  
>> A small screenshot of the new Inspector (WIP): 
>>  
>> 
>>  
>> Esteban

Re: [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

[PBKResearch]

+1 to Norbert. In particular, does it mean that, from Pharo 8, we will be 
*required* to install Gtk3 backend to use Pharo?

 

Peter Kenny

 

From: Pharo-users  On Behalf Of Norbert 
Hartl
Sent: 18 April 2019 11:58
To: Pharo users users 
Cc: Pharo Dev 
Subject: Re: [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

 

Great!

 

Can you explain what is there, what somebody can load and what to expect. And 
even more important: what not to expect?

 

I don’t get any of the essential details from this mail.

 

Norbert

 

 

Am 18.04.2019 um 12:08 schrieb Esteban Lorenzano <  
esteba...@gmail.com>:

 

People that assisted to Pharo Days 2019 (or that follow my twitter account) 
already know this, but it needs to be formally announced: 

 

We are working on Spec 2.0, and it will provide not just the classic Morphic 
bindings but also a new option for developers: Gtk3 bindings!

 

Why we want a Spec 2.0 with different backends?

 

There are reasons that converged to decide us to make it:

 

*   First, to provide a validated abstract Spec 2.0 that can be used with 
different backends, preparing Pharo to be able to switch backends without 
needing to recreate the full IDE from scratch each time (a problem we have 
partially now in our way to deprecate Morphic).
*   Second, because we receive from different sources the requirement of 
having the possibility of developing real native-looking desktop applications. 
Yes, in moment where people talk about the cloud, SaaS and web-applications as 
the "next big thing" (something that is been declared since years, by the way), 
we believe is important to provide this, for two big reasons: 

1.  Because there is still an important place for desktop applications 
market and most medium-size to big business still require them.
2.  Because Pharo itself is a desktop application! (And we need to provide 
the best experience possible on it).

 

For us, this is a fundamental step to continue improving Pharo itself, and it 
matches also the work we are doing on going real-headless:  Pharo users will be 
able to start the Morphic world, a Gtk application or the next backend to come.

 

Why Gtk3?

 

There are some other important players in the "native widgets scene", so why we 
choose Gtk3? 

 

Again, several reasons  were taken into account: 

 

*   Gtk3 is cross platform. Yes, technically is just "native" in linux, but 
it works on Windows and macOS too. 
*   It is very mature and popular.
*   It is made in plain C.

 

Next step: tool migration

 

The only way to know if you have covered what is needed is actually taking 
real-life use cases and implementing them. We have a list of tools that needs 
to be migrated and we are starting from them: 

 

1.  Old GT tools will be replaced by new Spec tools (while preserving its 
power).
2.  Calypso UI needs to be rewritten in Spec 2.0 (it is in plain Morphic 
now).
3.  Pharo launcher as a standalone application is a good example of what 
you can do with the Gtk3 bindings.

 

And that's it. Pharo 8.0 will come with Spec 2.0 and users will be able to 
benefit of it immediately :)

 

 

A small screenshot of the new Inspector (WIP): 

 



 

Esteban

 

Re: [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

[Norbert Hartl]

Great!

Can you explain what is there, what somebody can load and what to expect. And 
even more important: what not to expect?

I don’t get any of the essential details from this mail.

Norbert


> Am 18.04.2019 um 12:08 schrieb Esteban Lorenzano :
> 
> People that assisted to Pharo Days 2019 (or that follow my twitter account) 
> already know this, but it needs to be formally announced: 
> 
> We are working on Spec 2.0, and it will provide not just the classic Morphic 
> bindings but also a new option for developers: Gtk3 bindings!
> 
> Why we want a Spec 2.0 with different backends?
> 
> There are reasons that converged to decide us to make it:
> 
> First, to provide a validated abstract Spec 2.0 that can be used with 
> different backends, preparing Pharo to be able to switch backends without 
> needing to recreate the full IDE from scratch each time (a problem we have 
> partially now in our way to deprecate Morphic).
> Second, because we receive from different sources the requirement of having 
> the possibility of developing real native-looking desktop applications. Yes, 
> in moment where people talk about the cloud, SaaS and web-applications as the 
> "next big thing" (something that is been declared since years, by the way), 
> we believe is important to provide this, for two big reasons: 
> Because there is still an important place for desktop applications market and 
> most medium-size to big business still require them.
> Because Pharo itself is a desktop application! (And we need to provide the 
> best experience possible on it).
> 
> For us, this is a fundamental step to continue improving Pharo itself, and it 
> matches also the work we are doing on going real-headless:  Pharo users will 
> be able to start the Morphic world, a Gtk application or the next backend to 
> come.
> 
> Why Gtk3?
> 
> There are some other important players in the "native widgets scene", so why 
> we choose Gtk3? 
> 
> Again, several reasons  were taken into account: 
> 
> Gtk3 is cross platform. Yes, technically is just "native" in linux, but it 
> works on Windows and macOS too. 
> It is very mature and popular.
> It is made in plain C.
> 
> Next step: tool migration
> 
> The only way to know if you have covered what is needed is actually taking 
> real-life use cases and implementing them. We have a list of tools that needs 
> to be migrated and we are starting from them: 
> 
> Old GT tools will be replaced by new Spec tools (while preserving its power).
> Calypso UI needs to be rewritten in Spec 2.0 (it is in plain Morphic now).
> Pharo launcher as a standalone application is a good example of what you can 
> do with the Gtk3 bindings.
> 
> And that's it. Pharo 8.0 will come with Spec 2.0 and users will be able to 
> benefit of it immediately :)
> 
> 
> A small screenshot of the new Inspector (WIP): 
> 
> 
> 
> Esteban

Re: [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

[Esteban Lorenzano]

Ah yes… and same in morphic (but this is kind of boring ;): 




> On 18 Apr 2019, at 12:08, Esteban Lorenzano  wrote:
> 
> People that assisted to Pharo Days 2019 (or that follow my twitter account) 
> already know this, but it needs to be formally announced: 
> 
> We are working on Spec 2.0, and it will provide not just the classic Morphic 
> bindings but also a new option for developers: Gtk3 bindings!
> 
> Why we want a Spec 2.0 with different backends?
> 
> There are reasons that converged to decide us to make it:
> 
> First, to provide a validated abstract Spec 2.0 that can be used with 
> different backends, preparing Pharo to be able to switch backends without 
> needing to recreate the full IDE from scratch each time (a problem we have 
> partially now in our way to deprecate Morphic).
> Second, because we receive from different sources the requirement of having 
> the possibility of developing real native-looking desktop applications. Yes, 
> in moment where people talk about the cloud, SaaS and web-applications as the 
> "next big thing" (something that is been declared since years, by the way), 
> we believe is important to provide this, for two big reasons: 
> Because there is still an important place for desktop applications market and 
> most medium-size to big business still require them.
> Because Pharo itself is a desktop application! (And we need to provide the 
> best experience possible on it).
> 
> For us, this is a fundamental step to continue improving Pharo itself, and it 
> matches also the work we are doing on going real-headless:  Pharo users will 
> be able to start the Morphic world, a Gtk application or the next backend to 
> come.
> 
> Why Gtk3?
> 
> There are some other important players in the "native widgets scene", so why 
> we choose Gtk3? 
> 
> Again, several reasons  were taken into account: 
> 
> Gtk3 is cross platform. Yes, technically is just "native" in linux, but it 
> works on Windows and macOS too. 
> It is very mature and popular.
> It is made in plain C.
> 
> Next step: tool migration
> 
> The only way to know if you have covered what is needed is actually taking 
> real-life use cases and implementing them. We have a list of tools that needs 
> to be migrated and we are starting from them: 
> 
> Old GT tools will be replaced by new Spec tools (while preserving its power).
> Calypso UI needs to be rewritten in Spec 2.0 (it is in plain Morphic now).
> Pharo launcher as a standalone application is a good example of what you can 
> do with the Gtk3 bindings.
> 
> And that's it. Pharo 8.0 will come with Spec 2.0 and users will be able to 
> benefit of it immediately :)
> 
> 
> A small screenshot of the new Inspector (WIP): 
> 
> 
> 
> Esteban

[Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

[Esteban Lorenzano]

People that assisted to Pharo Days 2019 (or that follow my twitter account) 
already know this, but it needs to be formally announced: 

We are working on Spec 2.0, and it will provide not just the classic Morphic 
bindings but also a new option for developers: Gtk3 bindings!

Why we want a Spec 2.0 with different backends?

There are reasons that converged to decide us to make it:

First, to provide a validated abstract Spec 2.0 that can be used with different 
backends, preparing Pharo to be able to switch backends without needing to 
recreate the full IDE from scratch each time (a problem we have partially now 
in our way to deprecate Morphic).
Second, because we receive from different sources the requirement of having the 
possibility of developing real native-looking desktop applications. Yes, in 
moment where people talk about the cloud, SaaS and web-applications as the 
"next big thing" (something that is been declared since years, by the way), we 
believe is important to provide this, for two big reasons: 
Because there is still an important place for desktop applications market and 
most medium-size to big business still require them.
Because Pharo itself is a desktop application! (And we need to provide the best 
experience possible on it).

For us, this is a fundamental step to continue improving Pharo itself, and it 
matches also the work we are doing on going real-headless:  Pharo users will be 
able to start the Morphic world, a Gtk application or the next backend to come.

Why Gtk3?

There are some other important players in the "native widgets scene", so why we 
choose Gtk3? 

Again, several reasons  were taken into account: 

Gtk3 is cross platform. Yes, technically is just "native" in linux, but it 
works on Windows and macOS too. 
It is very mature and popular.
It is made in plain C.

Next step: tool migration

The only way to know if you have covered what is needed is actually taking 
real-life use cases and implementing them. We have a list of tools that needs 
to be migrated and we are starting from them: 

Old GT tools will be replaced by new Spec tools (while preserving its power).
Calypso UI needs to be rewritten in Spec 2.0 (it is in plain Morphic now).
Pharo launcher as a standalone application is a good example of what you can do 
with the Gtk3 bindings.

And that's it. Pharo 8.0 will come with Spec 2.0 and users will be able to 
benefit of it immediately :)


A small screenshot of the new Inspector (WIP): 



Esteban

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[Stephan Eggermont]

TedVanGaalen  wrote:
> Thanks for the Info/Link, Stephan
> 
> So it is a VM error then?
> 

That is what I asked you to verify. Does the problem occur with
20182039? If not, then it is probably the same bug. 

Stephsn

[Pharo-users] [ANN] Next Pharo Sprint: April 26

[Marcus Denker]

We will organize a Pharo sprint / Moose dojo April 26, starting at

10:00am. (Local Time Paris). 

Goals of this sprint:

- Pharo 8: Fix issues from tracker 
https://github.com/pharo-project/pharo/issues

Remote Sprint: Remotely, you can join us on Discord. During the sprint, we 
synchronize local and remote Pharo sprinters:

http://pharo.org/contribute-events

We have added a Board to coordinate the work:
https://github.com/orgs/pharo-project/projects/9

Known Local Sprint meetings

Lille/France:

It will be at the Inria Lille, Building B, third floor (RMoD offices). As the 
building is not open to the public, please contact us before if you plan to come

Re: [Pharo-users] glamorous toolkit forum/maillist

[Serge Stinckwich]

I think #gtoolkit channel on Discord is the best way to discuss with people.

On Tue, Apr 16, 2019 at 6:37 PM Steve Quezadas  wrote:

> Is there a forum or maillist for glamorous toolkit? I can't find anything
> on the official website or google searches.
>


-- 
Serge Stinckwic
​h​

Int. Research Unit
 on Modelling/Simulation of Complex Systems (UMMISCO)
​Sorbonne University
 (SU)
French National Research Institute for Sustainable Development (IRD)​
U
​niversity of Yaoundé I​, Cameroun
"Programs must be written for people to read, and only incidentally for
machines to execute."
https://twitter.com/SergeStinckwich
​

Re: [Pharo-users] Why are package tags not proper sub-packages?

[Ben Coman]

On Wed, 17 Apr 2019 at 05:53, Tim Mackinnon  wrote:

> Does anyone remember why we decided to consider package tags (as in:
> Kernel-BasicObjects) not fully fledged sub-packages?
>
> The implication here is that extension methods can’t live on the tag (they
> live on the parent package - in the above case Kernel - and not
> Kernel-BasicObjects), and equally the code critic works on the package
> level and not on an individual tag. Equally, refactoring can work at the
> package level … the list goes on.
>
> Having decided that it seemed to make it more understandable that Exercism
> exercises would simply be tags of the package exercism (its tidy to have
> the exercises neatly organised under a common parent with some generic menu
> options), I am finding that the above are starting to bite me. Extensions,
> Code critic (and sometimes refactoring) are awkward or more difficult to
> explain, and I was left wondering what the rational was to not make the
> tags fully fledged sub projects?
>

I hope someone involved in the design will answer in more detail,
but overall what I remember from observed discussions is that
in moving from string-based Categorizations to RPackage objects there was
a tough decision made to keep compatibility with strings for sake of
interchange with
other dialects - and *perhaps* that impacted how package tags were designed,
and our Exercism use case is now just exposing some gap there.


> I’m now wondering if I should bite the bullet and migrate every exercise
> tag to being a fully formed project (although in most cases it seems
> overkill for a class and a test).
>

I have also the feeling that it may be overkill, but I've come to the same
conclusion
that the exercises are probably better as separate packages.

cheers -ben