weak map gist

cache.ts

export class Cache<T extends object, K> {
	items = new WeakMap<T, K>()

	get<P extends T>(item: P, cb: (item: P) => K) {
		if (!this.items.has(item)) {
			this.items.set(item, cb(item))
		}
		return this.items.get(item)!
	}

	access(item: T) {
		return this.items.get(item)
	}

	set(item: T, value: K) {
		this.items.set(item, value)
	}

	has(item: T) {
		return this.items.has(item)
	}

	invalidate(item: T) {
		this.items.delete(item)
	}

	bust() {
		this.items = new WeakMap()
	}
}

gistfile1.ts

class Example {

  getOutline(shape) {
    const sides = 5 
        const ratio = 1
        const cx = w / 2
        const cy = h / 2
        const ix = (cx * ratio) / 2
        const iy = (cy * ratio) / 2
        const step = PI2 / sides / 2
        return Array.from(Array(sides * 2)).map((_, i) => {
          const theta = -TAU + i * step
          return new Vec2d(
            cx + (i % 2 ? ix : cx) * Math.cos(theta),
            cy + (i % 2 ? iy : cy) * Math.sin(theta)
          )
        })
  }

  outline(shape: T) {
    return outlines.get<T>(shape, (shape) => this.getOutline(shape))
  }

It's mentioned that the cache is slow. This is to be expected when using a WeakMap.

Was inverting the cache considered? Meaning storing the x,y cached properties inside each associated original shape (either as public or private fields). This ensures there is no increase in the count of objects and makes cache access super fast. I am wondering if fast caching changes the balance here.

Good point. For Steve's use-case it seems storing the entire outline array on the instance every time the shape transforms, might be viable. It does nothing for latency and uses more memory, but still, seems better than a WeakMap.