You cannot view this unit as you're not logged in yet. Go to Account to login.
19 Comments
Francisco Quinteroon November 24, 2020 at 7:02 pm
Awesome and thank you!
These pattern matching exercises have clear my mind and now I feel more confident. In the beginning I thought I wouldn’t complete the exercises without looking at the solution but gave them a try, read my notes, and tests passed!
The second one was a tricky one, though, but was a nice thing to learn.
It’s a good question and this may sound like I’m dodging the question, but I’d say it really depends. đŸ™‚
I prefer a case statement when the code is pretty simple. Like just a simple transformation. When the body of code in a case clause starts to get more involved or complex, I think about doing it differently. Separate function clauses can be easier to test as well.
Sometimes reading some code I notice I needed to practice and put in my mind exactly these things.
And here was a good sample to blow my mind.
I like the exercise with tests, It was very helpful.
In some books you don’t see this important things you need to understand and it’s very simple now for me.
Thank’s!
The 2nd exercise was difficult for me, I don’t know why. Maybe I need to get used to use pattern matching more often. I have all tests passed with this solution:
def has_three_elements?(tuple) do
tuple_size(tuple) == 3
end
Yes, that works! However you don’t get any of the benefits of pattern matching. What we’re building up to is letting the function header do the sorting for which function body will be executed. The pattern match replaces your conditional logic… gone are the days of multiple nested IF statements. Things become much clearer, easier to understand and maintain.
File `tuples_test.exs`, line 35, test described with “return major US holiday for the month”. you are using the match operator (`=`) all over the place. Is it (I presume) a bug or a feature?
Thanks for responding. Since I’m not sure how it would be a bug, I’ll say it’s a feature. The match operator is very powerful in Elixir. In a test, we can use the match operator to assert that it matches the pattern without having to provide an exact match of the value.
I gave it a thought and even though the match operator eventually produces a failed test I think it is misleading in the context of an `assert` evaluation. It could be a valid idiomatic usage of the match operator but I am not as experienced in the language as to avoid a little bit of astonishment while reading it.
Still, I am thankful to the course author to gave me the opportunity to think about this matter.
Awesome and thank you!
These pattern matching exercises have clear my mind and now I feel more confident. In the beginning I thought I wouldn’t complete the exercises without looking at the solution but gave them a try, read my notes, and tests passed!
The second one was a tricky one, though, but was a nice thing to learn.
Is it a better practice to create multiple function clauses or to create one clause with a case statement?
It’s a good question and this may sound like I’m dodging the question, but I’d say it really depends. đŸ™‚
I prefer a
casestatement when the code is pretty simple. Like just a simple transformation. When the body of code in a case clause starts to get more involved or complex, I think about doing it differently. Separate function clauses can be easier to test as well.Sometimes reading some code I notice I needed to practice and put in my mind exactly these things.
And here was a good sample to blow my mind.
I like the exercise with tests, It was very helpful.
In some books you don’t see this important things you need to understand and it’s very simple now for me.
Thank’s!
Awesome! I’m so glad you’re enjoying it!
Very helpful. Practice makes perfect. Thanks for putting this tutorial together.
Kinda reminds me of the Ruby Koans project, which was terrific.
This is really cool. Got my pattern-matching confidence on a solid level. Much appreciation for this awesome tutorials and tests.
Thank you, the best i found so far. Would buy the next course for sure.
Maybe you can do something with recursion? đŸ™‚
I’m glad it’s helpful! Yes, the CodeFlow course covers recursion along with a lot more.
The 2nd exercise was difficult for me, I don’t know why. Maybe I need to get used to use pattern matching more often. I have all tests passed with this solution:
def has_three_elements?(tuple) do tuple_size(tuple) == 3 endYes, that works! However you don’t get any of the benefits of pattern matching. What we’re building up to is letting the function header do the sorting for which function body will be executed. The pattern match replaces your conditional logic… gone are the days of multiple nested IF statements. Things become much clearer, easier to understand and maintain.
And I also interesting where’s exercise #4? why it’s missed.
Ha! That’s crazy that no one pointed that out before! There is no missing #4… the numbering was off. Fixed. Thanks!
Is the usage of the match operator in test “return major US holiday for the month” a bug or a feature?
Can you be more specific? What part of the usage or example do you mean?
File `tuples_test.exs`, line 35, test described with “return major US holiday for the month”. you are using the match operator (`=`) all over the place. Is it (I presume) a bug or a feature?
I am referring to the code in `pattern_matching.zip` with MD5 checksum: f6b0fdd34f7f534997bd2117cde97364
Thanks for responding. Since I’m not sure how it would be a bug, I’ll say it’s a feature. The match operator is very powerful in Elixir. In a test, we can use the match operator to assert that it matches the pattern without having to provide an exact match of the value.
Hope that helps.
I gave it a thought and even though the match operator eventually produces a failed test I think it is misleading in the context of an `assert` evaluation. It could be a valid idiomatic usage of the match operator but I am not as experienced in the language as to avoid a little bit of astonishment while reading it.
Still, I am thankful to the course author to gave me the opportunity to think about this matter.