Instructor: 00:02 Here, I've created a type alias dog and created the value of type dog. Now, when you define a type alias like this, it also creates a convenience function to create a value of that type. Instead of listing all the values like this, I could alternatively say, dog Fido Husky.
00:27 This will be the exactly the same as before. To prove this to you, let me say two string Fido. You can see this has built a record as you expected.
00:39 There is a problem with this approach however, and that's, if you have two fields with the same type as you have in this case two strings, and you then decide to refactor, so you'll see -- oh, let me have the breathe first -- and you compile, now you have obviously invalid data, because your breathe is Fido and the name is Husky.
01:02 On the other hand, if you use the notation we were using before, then even though the order of the fields is now different. The values are still applied to the fields as we would expect.
01:14 As you can see change in the order of the fields, if they are of the same type is not a safe for factoring. It's also possible to deconstruct records. Let me define a functional describe that takes a dog and returns a string, that's description of the dog.
01:36 We'll say d.name is a d.breathe. Let me demonstrate this. You can see this as Fido is a Husky. It is possible to do this slightly differently. Instead of d, you deconstruct your record inline and you can say this record will have a name and the breathe.
02:02 Here, you would just use these variables, name and breathe. Handle that these actually have to be the field names. If you said n and b, and used n and b. This will not compile, because the compiler is looking for fields called n and b, and it cannot find them on the type dog.