# Polymorphism

## Table of Contents
1. [Polymorphism Intro](#polymorphism)
2. [Polymorphism at the Library](#library)
3. [Project 2](#project2)
4. [Another Example](#another)
5. [Facebook Discussion!](#fb)

## Polymorphism Intro <A name="polymorphism"></A>

Polymorphism ("poly-": multiple, "morph-": shape), is the ability to write code that works over multiple data types. It’s very easy to write polymorphic functions in Python. For instance, what type does the following function return?

def add(x, y):
  return x + y

Depending on the type of its arguments, it could return an integer, a float, or a string. This property can be confusing! If we only plan on calling this function with a specific type, we might want to add annotations:

def add(x: str, y: str) -> str:
  return x + y

Polymorphic code can also be useful, though, as we’ll see below.

## Polymorphism at the Library <A name="library"></A>

Let’s revisit an example you might have seen in 0111: tracking items at a library. The library has both books and movies, and we can make classes for both of them:

class Book:
    def __init__(self, title: str, author: str):
        self.title = title
        self.author = author

class Movie:
    def __init__(self, title: str, director: str, actors: list):
        self.title = title
        self.director = director
        self.actors = actors

We can represent a library as a list of these items. Let's pick a book and a movie that Tim would like to read and watch this year:

library = [Book("The Nickel Boys", "Colson Whitehead"),
           Movie("Parasite", "Bong Joon-ho", ["Song Kang-ho", "Lee Sun-kyun"])]

An operation we might want on libraries is text search over library items. An advanced search might allow users to search over authors or directors, or search for particular item types (books or movies). In Pyret we would implement this by making books and movies constructors of the same datatype. We could do a similar thing in Python, but there’s another solution using polymorphism.

We'll add a method to each class:

class Book:
    def __init__(self, title: str, author: str):
        self.title = title
        self.author = author

    def matches(self, query: str) -> bool:
        return query in self.title or query in self.author

class Movie:
    def __init__(self, title: str, director: str, actors: list):
        self.title = title
        self.director = director
        self.actors = actors

    def matches(self, query: str) -> bool:
        return query in self.title or query in self.director or 
          any([query in actor for actor in self.actors])

Notice that I've used a function called `any` here, which you might not have seen before. It takes in a list of booleans and produces true if and only if any of those inputs is true. It's convenient for implementing this sort of method via a list comprehension.

Now we can implement our search function:

def search(library: list, query: str) -> list:
    return [item for item in library if item.matches(query)]

Let’s work though what happens when we call `search(library, "Colson")`. Here's what the state of the program dictionary and memory look like:


The list comprehension in `search` is going to look through everything in `library`: the book at index `0` and the movie at index `1`. In both cases, it will call the `matches` method of the object at hand, but let's be a bit more concrete about what each of those calls has to work with.

When the program is executing the `matches` method of the book, the program dictionary is _expanded_: `self` and `query` are known now, too!


I've put dotted lines around those 2 identifiers because they are freshly added for this call to `matches`. Once the program returns, those entries get removed. And when the movie's `matches` is called, the value of `self` changes.

### Preview

We'll come back to polymorphism on Friday, and you'll see some of the ways that Python uses it.

## Project 2 <A name="project2"></A>

Your next project is a very basic climate-change _simulator_.

Real climate simulation is challenging: there are many factors, both technical and social, that make modeling the problem complex. A _high quality_ simulation is therefore outside the scope of 112. But, much like we wanted you to get some practice with the ideas of machine learning, we also want you to get experience with building simulations.

So we've simplified the problem in a number of ways, including:
* the earth is one dimensional;
* there is only one molecule involved in temperature;
* there are no weather patterns, etc.

Exploring ways to remove some, but not all, of these limitations could make a good final project!

The challenge we've left is a geopolitical one. Different entities might implement different climage-change mitigation strategies: keeping emissions constant, scaling them back in specific ways, and so on. You'll be representing each of these strategies as its own class that informs the simulation via an `emit` method. Defining that method for each strategy class (What arguments does it take?) will be good practice at using both classes and polymorphism in Python.

So, in spite of the admittedly toy nature of the model, this project will give you valuable experience with:
* a new sort of application for computing; and
* object-oriented programming in Python.

You're allowed to partner with the same person on Project 2 if you'd like to, although we encourage branching out!

## Facebook Discussion <A name="fb"></A>

We'll spend the last 10 or 15 minutes of lecture discussing some of the resources posted on Friday about the Facebook Papers.

Discussions like this can happen at different levels of depth. We might start with:
* Facebook has not made enough effort to mitigate the impact of misinformation on its platform.

But let's set ourselves a higher standard. While true (at least in my opinion), the above statement needs more detail in order to really understand what the problem is:
* Facebook has automated measures to take down harmful content, but it doesn't apply those measures equitably across all its users. Some users, including politicians and celebrities, are often first manually reviewed by a Facebook employee before their content is taken down.

It's also useful to not just identify the problem, but:
* think through possible solutions (and new problems those might introduce!) or
* consider secondary effects that the problems might cause.

It's important to try to be mindful of this when we explore places where the technical and social meet (which is often where problems get both especially difficult _and_ important to solve, or at least to take steps toward solving).

With that context in mind, here are a few suggested discussion topics:
* What consequences did the recent Facebook downtime have? What factors made the problem worse? What technical or systemic failure led to the downtime in the first place, and how might that risk be reduced in the future?
* If Facebook doesn't apply the same criteria to everyone re: removing content, what consequences are there? What factors (business, systemic, technical, etc.) might contribute to Facebook's actions? What could be done?
* Facebook's algorithm has been said to confuse "engagement" with "anger". Is this a fair criticism? If so, what are the consequences? If not, what _is_ the way to phrase the issue, and what are the consequences of that?
* Facebook's review processes are heavily biased toward English-language content. What social threats might arise because of this? Is there a technical solution? If yes, what is it? If not, what could Facebook do?