From c3ea7d26e38a29f697675d7ce7f9ba0f22a8086c Mon Sep 17 00:00:00 2001
From: darkicewolf50 <brock.tomlinson@ucalgary.ca>
Date: Tue, 8 Apr 2025 11:54:40 -0600
Subject: [PATCH] finished ch19 intro

---
 .obsidian/graph.json              |  6 +++---
 .obsidian/workspace.json          | 22 +++++++++++++++++----
 Implementing OO Design Pattern.md |  2 +-
 Pattern Matching.md               | 33 +++++++++++++++++++++++++++++++
 Places Patterns Can Be Used.md    |  1 +
 5 files changed, 56 insertions(+), 8 deletions(-)
 create mode 100644 Places Patterns Can Be Used.md

diff --git a/.obsidian/graph.json b/.obsidian/graph.json
index 508340a..7c9bdab 100644
--- a/.obsidian/graph.json
+++ b/.obsidian/graph.json
@@ -1,6 +1,6 @@
 {
-  "collapse-filter": true,
-  "search": "",
+  "collapse-filter": false,
+  "search": "more information than the compiler",
   "showTags": false,
   "showAttachments": false,
   "hideUnresolved": false,
@@ -18,5 +18,5 @@
   "linkStrength": 1,
   "linkDistance": 250,
   "scale": 0.8410178518902366,
-  "close": false
+  "close": true
 }
\ No newline at end of file
diff --git a/.obsidian/workspace.json b/.obsidian/workspace.json
index b4fd9a2..206720d 100644
--- a/.obsidian/workspace.json
+++ b/.obsidian/workspace.json
@@ -49,6 +49,20 @@
               "title": "Pattern Matching"
             }
           },
+          {
+            "id": "78cd7043d5d51ffa",
+            "type": "leaf",
+            "state": {
+              "type": "markdown",
+              "state": {
+                "file": "Places Patterns Can Be Used.md",
+                "mode": "source",
+                "source": false
+              },
+              "icon": "lucide-file",
+              "title": "Places Patterns Can Be Used"
+            }
+          },
           {
             "id": "6ed9f182aa3d5f3e",
             "type": "leaf",
@@ -60,7 +74,7 @@
             }
           }
         ],
-        "currentTab": 2
+        "currentTab": 3
       }
     ],
     "direction": "vertical"
@@ -203,10 +217,11 @@
       "command-palette:Open command palette": false
     }
   },
-  "active": "629d55df46f486d8",
+  "active": "78cd7043d5d51ffa",
   "lastOpenFiles": [
-    "Implementing OO Design Pattern.md",
     "Pattern Matching.md",
+    "Places Patterns Can Be Used.md",
+    "Implementing OO Design Pattern.md",
     "Trait Objects that allow for Values of Different Types.md",
     "Characteristics of OO Languages.md",
     "OOP Programming Features.md",
@@ -230,7 +245,6 @@
     "The Performance Closures and Iterators.md",
     "Improving The IO Project.md",
     "Tests.md",
-    "The Preformance Closures and Iterators.md",
     "minigrep/src/lib.rs",
     "does_not_compile.svg",
     "Untitled.canvas",
diff --git a/Implementing OO Design Pattern.md b/Implementing OO Design Pattern.md
index 3474e91..958e973 100644
--- a/Implementing OO Design Pattern.md	
+++ b/Implementing OO Design Pattern.md	
@@ -346,7 +346,7 @@ Then we call the `unwrap` method, we know this will never panic.
 
 We know the methods on `Post` ensure that `state` will always contain a `Some` value when those methods are done.
 
-This is a case where we have more information than the compiler (previously discussed in [Ch 9]()) when we know that a `None` value is never possible, even though the compiler isn't able to understand that.
+This is a case where we have more information than the compiler (previously discussed in [Ch 9](./Error%20Handling.md#cases-in-which-you-have-more-info-than-the-compiler)) when we know that a `None` value is never possible, even though the compiler isn't able to understand that.
 
 Now at this point, when we call `content` on the `&Box<dyn State>`, deref coercion will take effect on the `&` and the `Box` so the `content` method will ultimately be called on the type that implements the `State` trait.
 
diff --git a/Pattern Matching.md b/Pattern Matching.md
index 50821a3..3dd1dbb 100644
--- a/Pattern Matching.md	
+++ b/Pattern Matching.md	
@@ -1 +1,34 @@
 # Patterns and Matching
+*Patterns* are a special syntax in Rust for matching against the structure of types, both complex and simple.
+
+Using patterns in conjunction with `match` expressions and other constructs give you more control over a program's flow.
+
+A pattern consists of some combination of the following:
+- Literals
+- Destructured arrays, enums, structs, or tuples
+- Variables
+- Wildcards
+- Placeholders
+Some examples include `x`, `(a, 3)` and `Some(Color::Red)`.
+
+In the contexts in which patterns are valid, these components describe the shape of data.
+
+Our program then matches values against the patterns to determine whether it has the correct shape of data to continue running a particular piece of code.
+
+In order to use a pattern, we compare it to some value.
+
+If the pattern matches the value, we use the value parts in our code.
+
+Recall the `match` expression that used patterns, such as the coin-sorting machine example.
+
+If the value fits the shape of the pattern, we can use the named pieces.
+
+If it doesn't, the code associated with the pattern won't run.
+
+This chapter is intended to be a reference on all things related to patterns.
+
+We will cover:
+- Valid places to use patterns [Section Link Here]()
+- Difference between refutable and irrefutable patterns
+- different kinds of pattern syntax
+By the end you will know how to use patterns to express many concepts in a clear way.
\ No newline at end of file
diff --git a/Places Patterns Can Be Used.md b/Places Patterns Can Be Used.md
new file mode 100644
index 0000000..f9bfc92
--- /dev/null
+++ b/Places Patterns Can Be Used.md	
@@ -0,0 +1 @@
+# All the Places Patterns Can Be Used