Robot name is considered reset when just set to `nil`

[exercism]

Robot name is considered reset when just set to `nil`

[PurityControl]

Going one stage further back than reset-name, as I read it, build-robot should return a robot without a name. The name should only be generated once the robot is initially booted up.

[kytrinyx]

I would also be happy to make the README more ambiguous to allow for more leeway in the solutions.

[verdammelt]

but reset-name should at least provide the robot with a new name
@wobh

My reading of the README says that reset-name should not give the robot a name, but the robot will get a new name "when asked". So it looks like my implementation (in the example file) is wrong according to the README since it assigns a name to the robot when the robot is created and when the robot is reset.

The API defined/implied by the README & tests does not provide a way to find out if a robot does not have a name. If you ask a robot their name that boots the robot up and a name is assigned.

The tests do not currently force the implementor to the specification defined in the README re: the name.

Perhaps if we separate 'booting' the robot from 'asking its name' so that we can ask the name and check that is not set until the robot is booted.

Or we leave it as is and pushing the implementor to the specification of the README is part of the nit-picking process?

In either case we should reimpliment the example to fit the README.

[wobh]

I could go along with that. I would want reset to set the robot to it's initial state (the single-state of these robots notwithstanding), where reset-name still seems like it should get the robot a new name.

Maybe this raises higher level questions about the pedagogical values intended for the exercise.

[kytrinyx]

I would be happy to fix the README on this one. I originally made it after helping a student explore the idea of memoization in Ruby.

[verdammelt]

What changes do we want to make? If we make too many changes then that would affect other languages right?

Maybe we just want to change:

Every once in a while we need to reset a robot to its factory settings,
which means that their name gets wiped. The next time you ask, it gets a
new name.

to something like:

Every once in a while we need to reset a robot to its factory settings,
which means that they will have a different name when they are next asked for their name.

[wobh]

On the one hand:

https://github.com/exercism/xruby/blob/master/robot-name/robot_name_test.rb#L34
https://github.com/exercism/xhaskell/blob/master/robot-name/robot-name_test.hs#L45
https://github.com/exercism/xclojure/blob/master/robot-name/robot_name_test.clj#L22
https://github.com/exercism/xscala/blob/master/robot-name/src/test/scala/robot_name_test.scala#L29
https://github.com/exercism/xpython/blob/master/robot-name/robot_name_test.py#L42

On the other hand:

https://github.com/exercism/xscheme/blob/master/robot-name/robot-name-test.scm#L32
https://github.com/exercism/xgo/blob/master/robot-name/robot_name_test.go#L40

Neither an exhaustive nor significant sampling, but so far it seems like more languages are testing that the robot has a valid name after reset.

[kytrinyx]

I like the ambiguity of your second suggestion, @verdammelt:

Every once in a while we need to reset a robot to its factory settings,
which means that they will have a different name when they are next asked for their name.

[verdammelt]

@kytrinyx

It does leave the implementation open. If we wanted to go the other way (stricter reading of robot not having a name after reset until asked) then we'd need to add a new function to the interface such as has-name?, but doesn't seem like it would be useful except for tests.

@wobh

So all those examples test that the name is not the same before and after reset. Some also check that the new name doesn't break the contract of the name accessor function. My opinion is that checking that the name is in the right format isn't needed in this case because one has already checked that in another test.

[verdammelt]

@kytrinyx @wobh

So what is the next step here?

[wobh]

I'm just going to close this.

[kytrinyx]

Good call :) thanks, @wobh