elbow-jason · September 26, 2019 17:15
diff --git a/000_what_is_nil.ex b/000_what_is_nil.ex

 x = nil

 # Q: What is x?

 # Q: What type is it?

 # Q: What does it represent?
diff --git a/001_blank.md b/001_blank.md
diff --git a/002_what_is_nil_answered.ex b/002_what_is_nil_answered.ex



 x = nil

 # Q: What is x?
 # A: x is nil

 # Q: What type is it?
 # A: Technically x is an atom, but this atom has special treatment in Elixir/Erlang.

 assert is_nil(x) == true
 assert is_atom(x) == true

 # Q: What does it represent?
 # A: It is tempting to say that it represents a missing value.

 # While in the context of it's creation nil may represent "a missing value", but outside of the
 # context of it's creation nil represents a total loss of type information. Effectively, nil becomes
 # a placeholder for any type.

 # The following examples focus on nil, but in reality any unexpected type is bad; and some of them
 # are much worse than nil.

diff --git a/010_collections_are_complex.md b/010_collections_are_complex.md
diff --git a/011_stringy_user_baddest.ex b/011_stringy_user_baddest.ex


 defmodule User do
  def build(params) do
    %{
      "name" => params["name"],
      "age" => params["age"]
    }
  end
 end

 # Q: What is the type of params?
 # A: "WHO KNOWS?"

 # Q: What is the type of the "name" field? "age"?
 # A: "WHO KNOWS?"

 # Q: Is the following a user? %{"name" => "Jason", "age" => "21"} 
 # A: No way to tell.
diff --git a/012_stringy_user_less_badder.ex b/012_stringy_user_less_badder.ex

 defmodule User do
  def build(params) do
    %{
      "name" => params["name"],
      "age" => params["age"],
      "__type__" => "User"
    }
  end
 end

 # Q: What is the type of params?
 # A: "WHO KNOWS?"

 # Q: Is the following a user? %{"name" => "Jason", "age" => "21", "__type__" => "User"}
 # A: Maybe

 # Q: What are the *intended* types?
 # A: "WHO KNOWS?"

 # Q: Are the types ever checked?"
 # A: "WHO KNOWS?"

 # Q: Did the compiler help me at all?
 # A: Only with syntax.

 # Q: Where do User functions go?
 # A: "WHO KNOWS?"

 # Q: How can we find the user functions given our user?
 # A: Can't without a lookup that returns `User`.
diff --git a/013_stringy_user_little_less_badder.ex b/013_stringy_user_little_less_badder.ex
 defmodule User do
  def build(params) do
    %{
      "name" => params["name"],
      "age" => params["age"],
      "__type__" => User
    }
  end
 end

 # Q: What is the type of params?
 # A: "WHO KNOWS?"

 # Is the following a user %{"name" => "Jason", "age" => "21", "__type__" => User}
 # A: Maybe

 # Q: What are the *intended* types?
 # A: "WHO KNOWS?"

 # Q: Are the types ever checked?"
 # A: "WHO KNOWS?"


 # Q: Did the compiler help me at all?
 # A: Only with syntax.

 # Q: Where do User functions go?
 # A: Maybe in the User module

 # Q: How can we find the user functions given our user?
 # A: The `User` module is on the map as `"__type__"`.
diff --git a/014_struct_user_bad.ex b/014_struct_user_bad.ex

 defmodule User do
  defstruct name: nil,
            age: nil
            
  def build(params) do
    %User{
      name: params["name"],
      age: params["age"],
    }
  end
 end

 # Q: What is the type of params?
 # A: "WHO KNOWS?"

 # Is the following a user %User{"name" => "Jason", "age" => "21"}
 # A: Yes

 # Q: What are the *intended* types?
 # A: "WHO KNOWS?"

 # Q: Are the types ever checked?"
 # A: "WHO KNOWS?"

 # Q: Did the compiler help me at all?
 # A: The compiler can now enforce the existance of our User keys for User literals.

 # User literal - Will compile
 %User{
  name: "Mackey",
  age: :yes,
 }

 # bad User literal - Will not compile
 %User{
  name: "Mackey",
  age: :yes,
  what_is_this?: "An invalid key!"
 }

 # Q: Where do User functions go?
 # A: In the User module

 # Q: How can we find the user functions given our user?
 # A: The `User` module is on the map as `:__struct__` field.
diff --git a/015_struct_user_bad_check_params.ex b/015_struct_user_bad_check_params.ex
 defmodule User do
  defstruct name: nil,
            age: nil
            
  def build(%{"name" => name, "age" => age}) do
    %User{
      name: name,
      age: age,
    }
  end
 end

 # Q: What is the type of params?
 # A: It's a map!

 # Is the following a valid user %User{"name" => "Jason", "age" => "21"}
 # A: "WHO KNOWS?"

 # Q: What are the *intended* types?
 # A: "WHO KNOWS?"

 # Q: Are the types ever checked?"
 # A: "WHO KNOWS?"

 # Q: Did the compiler help me at all?
 # A: The compiler can now enforce the existance of our User keys for User literals.

 # Q: Where do User functions go?
 # A: In the User module

 # Q: How can we find the user functions given our user?
 # A: The `User` module is on the map as `:__struct__` field.
diff --git a/016_user_struct_getting_better.ex b/016_user_struct_getting_better.ex
 defmodule User do
  defstruct name: nil,
            age: nil
            
  def build(params) do
    %User{
      name: parse_name(params),
      age: parse_name(params),
    }
  end
  
  defp parse_age(%{"age" => age}), do: age
  defp parse_age(_), do: nil
  
  defp parse_name(%{"name" => name}), do: name
  defp parse_name(_), do: nil
 end

 # Q: What is the type of params?
 # A: It's a map!

 # Is the following a valid User %User{"name" => "Jason", "age" => "21"}
 # A: "WHO KNOWS?"

 # Q: What are the *intended* types?
 # A: `:name` is supposed to be a string and `:age` supposed to be an integer

 # Q: Are the types ever checked?"
 # A: Yes!

 # Q: Did the compiler help me at all?
 # A: The compiler can now enforce the existance of our User keys for User literals.

 # Q: Where do User functions go?
 # A: In the User module

 # Q: How can we find the user functions given our user?
 # A: The `User` module is on the map as `:__struct__` field.

 # Issues:

 # Is age a less than zero? `nil`? a string? a stringy-map?
diff --git a/017_which_is_better.md b/017_which_is_better.md
diff --git a/018_much_better_way_but_will_crash.ex b/018_much_better_way_but_will_crash.ex
 defmodule User do
  defstruct name: nil,
            age: nil
            
  def build(params) do
    %User{
      name: parse_name(params),
      age: parse_name(params),
    }
  end
  
  defp parse_age(%{"age" => age}) when is_integer(age) and age >= 0, do: age
  
  defp parse_name(%{"name" => name}) when is_binary(name) do
    if String.printable?(name) do
      name
    else
      raise "name must be a string"
    end
  end
 end

 # This example is very safe for runtime types, but it will crash on bad inputs.
 # There is a less-crashy way.
diff --git a/019_less_crashy_okay_way.ex b/019_less_crashy_okay_way.ex
 defmodule User do
  defstruct name: nil,
            age: nil
            
  def build(params) do
    with(
      {:ok, name} <- parse_name(params),
      {:ok, age} <- parse_age(params),
    ) do
      user = %User{
        name: name,
        age: age,
      }
      {:ok, user}
    else
      {:error, _} = err -> err
    end
  end
  
  defp parse_age(%{"age" => age}) when is_integer(age) and age >= 0, do: {:ok, age}
  defp parse_age(%{"age" => _}), do: {:error, {:age, "must be a non-negative integer"}}
  defp parse_age(_), do: {:error, {:age, "is a required key"}}
  
  defp parse_name(%{"name" => name}) when is_binary(name) do
    if String.printable?(name) do
      {:ok, name}
    else
      {:error, {:name, "must be a string"}}
    end
  end
  
  defp parse_name(_) do
    {:error, {:age, "is a required key"}}
  end 
 end

 # This example gives us type checking, and a crash-free way to parse our user.
 # However we must (ideally) ensure our error returns are homogenous and only one error can be reported at a time.
 # Very procedural
diff --git a/020_best.ex b/020_best.ex
 defmodule User do
  use Ecto.Schema
  alias Ecto.Changeset
  
  embedded_schema do
    field(:name, :string)
    field(:age, :integer)
  end
            
  def changeset(%User{} = user, params) do
    user
    |> Changeset.cast(params, [:name, :age])
    |> Changeset.validate_required([:name, :age])
    # maybe not the actual call, but you get the idea
    |> Changeset.validate_number(:age, gte: 0)
  end
 end

 # This example is best for runtime.
 # Benefits:
  # type checking
  # multi-error reporting
  # delarative types
  # idiomative
  # 1/2 the lines of code

 # Drawbacks
  # boring
  
 # Benefits
  # boring
diff --git a/040_accessing_data.md b/040_accessing_data.md

	x = nil

	# Q: What is x?

	# Q: What type is it?

	# Q: What does it represent?



	x = nil

	# Q: What is x?
	# A: x is nil

	# Q: What type is it?
	# A: Technically x is an atom, but this atom has special treatment in Elixir/Erlang.

	assert is_nil(x) == true
	assert is_atom(x) == true

	# Q: What does it represent?
	# A: It is tempting to say that it represents a missing value.

	# While in the context of it's creation nil may represent "a missing value", but outside of the
	# context of it's creation nil represents a total loss of type information. Effectively, nil becomes
	# a placeholder for any type.

	# The following examples focus on nil, but in reality any unexpected type is bad; and some of them
	# are much worse than nil.


	defmodule User do
	def build(params) do
	%{
	"name" => params["name"],
	"age" => params["age"]
	}
	end
	end

	# Q: What is the type of params?
	# A: "WHO KNOWS?"

	# Q: What is the type of the "name" field? "age"?
	# A: "WHO KNOWS?"

	# Q: Is the following a user? %{"name" => "Jason", "age" => "21"}
	# A: No way to tell.

	defmodule User do
	defstruct name: nil,
	age: nil

	def build(params) do
	%User{
	name: params["name"],
	age: params["age"],
	}
	end
	end

	# Q: What is the type of params?
	# A: "WHO KNOWS?"

	# Is the following a user %User{"name" => "Jason", "age" => "21"}
	# A: Yes

	# Q: What are the intended types?
	# A: "WHO KNOWS?"

	# Q: Are the types ever checked?"
	# A: "WHO KNOWS?"

	# Q: Did the compiler help me at all?
	# A: The compiler can now enforce the existance of our User keys for User literals.

	# User literal - Will compile
	%User{
	name: "Mackey",
	age: :yes,
	}

	# bad User literal - Will not compile
	%User{
	name: "Mackey",
	age: :yes,
	what_is_this?: "An invalid key!"
	}

	# Q: Where do User functions go?
	# A: In the User module

	# Q: How can we find the user functions given our user?
	# A: The `User` module is on the map as `:__struct__` field.
	defmodule User do
	use Ecto.Schema
	alias Ecto.Changeset

	embedded_schema do
	field(:name, :string)
	field(:age, :integer)
	end

	def changeset(%User{} = user, params) do
	user
	\|> Changeset.cast(params, [:name, :age])
	\|> Changeset.validate_required([:name, :age])
	# maybe not the actual call, but you get the idea
	\|> Changeset.validate_number(:age, gte: 0)
	end
	end

	# This example is best for runtime.
	# Benefits:
	# type checking
	# multi-error reporting
	# delarative types
	# idiomative
	# 1/2 the lines of code

	# Drawbacks
	# boring

	# Benefits
	# boring