I like this. Robot could address the slight weirdness of having to create empty structs just so they can implement an interface, and BaggageHandlerRobot would be good to have another struct implementing Greeter, but also to show that the same struct can implement different interfaces.
But I’ll wait for @junedev to weigh in as the original creator of the exercise.
This was a hard exercise to create in the first place and I am also not super happy with it. But at the same time, I am also not completely sold to the proposed alternative as it puts a lot of focus on the OOP/constructor part which is not the main point of the exercise. I would like to ponder the topic a bit more, maybe wait for some more feedback etc before doing another iteration.
Currently the completion rate is 90% (same as Annalyns infiltration) and no. of attempts is rather low with 4 for the exercise so I don’t feel the rework is very urgent.
My main confusion with the exercise was not knowing how to implement the structs. What properties should they have? How were they instantiated? I had to read the tests for that.
If the stub file looked more like this, it might be clearer:
package airportrobot
// Add the Greeter interface here
// Add the SayHello function here.
// These types will implement the Greeter interface.
// These are empty structs. This is OK for the purposes of this exercise.
type Italian struct{}
type Portuguese struct{}
// Implement the Greeter interface here for the types listed above.
The concept exercism completion stats for Go are very impressive. That speaks to the care you’ve put into designing them. If any of my suggestions are unwanted or unneeded, no worries.
@glennj Thanks for your nice words regarding the track. I am of course happy to hear your feedback, I just wanted to explain why I am not jumping right in to apply changes.
I like the idea of clarifying the empty structs are ok.