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.

Last time around, we got to Better Know access control in Ruby, and I started to write my opinion on the use of private methods in Ruby, but my position/argument/rant had gotten out of hand and so I spun it off into its own post. This is that post. It’s long enough as it is, let’s just get to it, we’ll skip the internal ad. What I think about Private Methods in Ruby In Ruby, a method without side effects should be public.

I’ll be honest, I picked this topic out of the half-dozen or so Better Know A Ruby Things on my to-do list strictly because it’s maybe the only Ruby take that I genuinely argue with people about. To be even more honest, it got away from me a bit as I started writing the argument: which is why I tend to avoid declaring methods private. I know these newsletters have tended toward long, but 3100+ words was a bit much even for me, so I’ve split it in half.

If your organization has coders continually getting in each other’s way, or if you make a change to part of your code base and don’t know who needs to review it, or if you have code that nobody maintains because everybody owns it… you may be violating Conway’s Law. Hi – I thought I’d do something a little different this time. We’ll be back to more Better Know Ruby things next time, but I’ve been sitting on this essay for a while and wanted it to get out.

This is late even by my absurd standards for having this post be late. I have a good excuse – I got on to TikTok. And not that I wasted a bunch of time on TikTok, but that I started to see a lot of BookTok videos, where a lot of very earnest people would talk about their 5-star-books for November or whatever. And I thought, “Do I sound like that?

Previously in what what I guess is now “The Argument Trilogy”, we talked about: Positional Arguments Keyword Arguments And now the trilogy now comes to its inevitable conclusion with “Return of The Jedi” block arguments. In the interest of keeping this thing within the plausible word count of a newsletter, we’re not going to talk about what blocks are or the way blocks behave here, that’ll be a future Better Know, but we do need to talk about block syntax.

Last time on Better Know A Ruby Thing, we covered positional arguments, and now we’re going to move on to keyword arguments. I really did think this was going to be shorter than the last one, and then I got to the conversion between keyword and positional arguments, and then… well, it’s not shorter. (I know I said the next newsletter was going to be Conway’s Law, that’s coming, but this one moved along faster…)

Ruby has three ways to pass information from a method call to a method definition: positional arguments, keyword arguments, and block arguments. Each of these ways has: A syntax to declare an argument of that type in a method definition A syntax to declare an argument of that type in a method call A class that can can be used to convert arbitrary objects into and out of method calls A text marker that is associated with that kind of argument, *, **, or &.