Noel Rappin Writes Here

Last time, I talked about ways to use dynamic typing to manage objects and business logic in your code. Doing so involves leaning into the object system, going beyond just “one class for each noun” and creating objects to model different states within the business logic directly. In a basic Object-Oriented design, you might have an object called User. This object, by itself, represents the entire concept of a user within the system.

How To Not Use Static Typing In Ruby Last time, I took a short example and examined in some detail what you would gain by adding static typing to it and what it would cost to use static typing. What I didn’t do was explain how I might handle the problem without static typing. For reference, Here’s the example again. Consider this to be part of a larger system and don’t worry too much about the rest of the world:

I’ve tried writing this literally a half-dozen times. And it always feels like it slips out of control and gets too abstract to be useful. So, let’s start with something concrete. And we’re going to wind up splitting this into multiple parts. Probably two, but honestly, at this point who knows? This all got started because I was discussing the use of runtime checking using Sorbet. The other person gave me a code snippet and asked how I would manage it without type checking.