1. 27
    Rustlings enums3: Working with enums by pattern matching variants
    3m 13s

Rustlings enums3: Working with enums by pattern matching variants

Chris Biscardi
InstructorChris Biscardi
Share this video with your friends

Social Share Links

Send Tweet
Published 4 years ago
Updated 3 years ago

README for this exercise.

Chris Biscardi: [0:00] In enums3, we have to address all the TODOs to make the test pass. We have a one TODO inside of our empty Message enum that we have to fill in. We have to go discover all the Message variant types that this enum will need to support.

[0:13] Note that we have a Point struct here, a State struct, and an imp State struct that attaches a number of methods. These include change_color, quit, echo, move_position, and process. Process is an empty body that we have to fill in.

[0:30] In our test, we have a function called test_match_message_call() where we instantiate a new State struct, and then we have state.process each of our messages that come from the enums.

[0:39] Note that some of the errors that the Rust compiler gives us are that we have no variant named 'Move' for enum 'Message' and other such missing variants. We'll do those first.

[0:48] We need to :ChangeColor, :Echo, :Move, and :Quit. Note that I've chosen types for the enums that match the color State, the change_color() function, or the Point struct. All of our numbers are u8 bit integers, so that's what I used. Also note that Echo takes a string, so I've added that as well.

[1:05] Now that our struct is filled out, we can see that some of our tests are not passing. The first one that isn't passing is related to the change_color() function. When we process this ChangeColor, we aren't applying the values.

[1:16] Inside of process, it tells us to create a match expression. We'll match on Message. We'll match on ChangeColor. For change_color, State has another function called change_color() whose first argument is mutable self, and second argument is a color tool.

[1:30] To access this function, we'll use self which is also an argument to process. Note that I've called self.change_color with (r, g, b) as a tuple. We do have one more problem. ChangeColor isn't found in the scope even though we've defined it up top. This is because ChangeColor is inside of the Message enum, so we must use this very specific syntax to access it.

[1:51] Now that we've implemented ChangeColor in our match expression, we can see that we have a non-exhaustive pattern match. We're matching on ChangeColor, but we aren't matching on any of the other variants, such as 'Echo(_)', 'Move { ... }', and'Quit'. We'll add those in now.

[2:04] Note that we also have to namespace Echo, Move, and Quit. After pattern matching on Echo, Move, and Quit, we bootstrapped them with empty blocks that don't do anything. This is fine because process doesn't return anything, so we can use this as a placeholder while we figure out what's wrong with our test.

[2:19] Our next assertion says left '', right '10' which is the assert_eq! On state.position.x. It is related to the Move variant in the Message enum. If we look at State, we can see that there's a move_position() function that we should use. The move_position() function takes a point. When instantiating a new point, we can pass in the x and y.

[2:38] The next test that's failing is for state.quit. We'll call self.quit when we match on Message: :Quit. Note that all of the tests have passed. There is one more function we can implement.

[2:48] Because the tests match when we were on state.process, Message: :Echo with a String, currently, our empty block satisfies that constraint. We also have an echo() function on our State implementation, so let's implement that.

[3:00] After calling Echo, we've implemented all of the variants on our Message using a match. We've pattern matched on each of the variants and their values, and then called methods that are on the implementation for State with their values.

egghead
egghead
~ just now

Member comments are a way for members to communicate, interact, and ask questions about a lesson.

The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io

Be on-Topic

Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.

Avoid meta-discussion

  • This was great!
  • This was horrible!
  • I didn't like this because it didn't match my skill level.
  • +1 It will likely be deleted as spam.

Code Problems?

Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context

Details and Context

Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!

Markdown supported.
Become a member to join the discussionEnroll Today