"Just give me an escape hatch!" Sooner or later, almost all reusable code that tries to draw a hard abstraction boundary around implementation details ends up with a request for direct access to things that were designed to be hidden. There's some use case that doesn't quite work ergonomically - or at all - with the current interface, and the easiest solution is to offer an escape hatch that pokes a hole in the boundary.
Sometimes, an escape hatch may be the best way to handle these situations. But what about the downsides? If these solutions were all sunshine and rainbows, we'd probably call them something more like "front doors" than "escape hatches"—and unfortunately, many of the downsides aren't obvious at first. It's easy to overlook or underestimate (until it's too late) certain costs of introducing an escape hatch to a design, and just as easy to use one without realizing it opens into a pit of despair.
This talk will dive into some of the least-discussed tradeoffs associated with escape hatches in code. Come see how you can get the most out of this common technique while avoiding the pitfalls!
Richard is the creator of the Roc programming language, the author of “Elm in Action” from Manning Publications, the host of the podcast Software Unscripted, and the instructor for several Frontend Masters workshops: Introduction to Elm, Advanced Elm, and Introduction to Rust. He currently works at Zed Industries on helping to make Zed the best code editor in the world....