pcantrell

Map and HashMap

Learning objectives:

pcantrell

body.app-body.layout-multiple-columns.theme-mastodon-light,
body.app-body.layout-multiple-columns.theme-default,
body.app-body.layout-multiple-columns.theme-contrast {
  overflow: hidden !important;
}

body.app-body.layout-multiple-columns.theme-mastodon-light .columns-area,
body.app-body.layout-multiple-columns.theme-default .columns-area,
body.app-body.layout-multiple-columns.theme-contrast .columns-area {
  margin: 0 -1px !important;

pcantrell

# How can we harmonize the types of a Square class and a Rectangle class
# so that it's possible to write a rescale function that works on both?
#
# As we saw in class Wed, if we’re doing this in Java, inheritance cannot
# solve this problem in a simple way: both `Square extends Rectangle`
# and `Rectangle extends Square` end up violating the Liskov Substitution
# Principle. While there is a nice “is-a” relationship here — all squares
# are rectangles! — that does not translate nicely into Java’s type system.
#
# In class today, we saw that having one inherit from the other doesn’t

pcantrell

# ------ Base class with metaprogramming ------

# This might make more sense if you skip ahead to the 🦄🦄🦄🌈🌈🌈 first
# and study the desired results, then come back here.

class Animal
  def initialize(name)
    @name = name
  end

pcantrell

Turning programmer errors into type errors

An example problem

In Wordy, suppose that BinaryExpressionNode were designed like this, with the operator modeled as a string:

public class BinaryExpressionNode extends ExpressionNode {
    // Valid operator types include "addition", "subtraction", "multiplication",
 // "division", and "exponentiation". Other strings are not valid operators.

pcantrell

Swift Evolution proposals for the three features I covered:

• Dynamic Member Lookup
• Dynamic Callable
• Key Path Member Lookup

Here's a good (and mildly critical) overview of dynamic member lookup.

Python interop:

• Library to use Python with normal Swift
• Plotting library I used in tonight’s demo

pcantrell

import Foundation

// WHY HAVE A TIMER SYNCED TO DISPLAY REFRESH?
// 
// Sparked by this question from Nick Lockwood:
// https://twitter.com/nicklockwood/status/1131650052701786114

class TimerPhasingSimulation
    {
    // –––––– Heart of the simulation ––––––

pcantrell

Goals

• Create a standard way for devs to document what assumption led them to use an unsafe operation (e.g. force unwrap).
• Cover all trapping operations (!, try!, as!, []) through a single mechanism. (Lack of this seems to have been Lattner’s primary beef with the previous proposal.)
• Make this mechanism work as both:
  • developer documentation — clear, readable, and not excessively noisy in the code itself — and
  • runtime diagnostic, included in console / crash logs to expedite debugging.

Solution

pcantrell

1. Generalized existentials 😄 In progress!

   • Use case: implement Resource<T>, Siesta’s most obvious API design gap
   • Use case: silly dances like this

2. ✅ $0 ≠ all params

3. Fix anonymous closure argument goofiness (bug, older bug)

• Use case: I specifically made the more-frequently used closure arg the second one here so that code referencing only it as $1 would compile (where it would not if it were $0)

pcantrell

// Siesta’s Resource class represents the current “best information available”
// about a RESTful resource. Other parts of the code can observe changes to
// that state (started loading, received new data, received error, etc):

public protocol ResourceObserver
    {
    func resourceChanged(_ resource: Resource, event: ResourceEvent)
    // (plus other stuff I’m ignoring)
    }