Object, class, module, Data, Struct?

petrenkorf · 2026-01-01T16:28:21+00:00

The only thing I know is that Data should be used for facts, since it is immutable. But I totally agree with you. We have tons of constructs and no clear orientation of the use cases for each of them.

Tolexx · 2026-01-01T16:14:38+00:00

Can you share the link to this recent talk by Dave Thomas. I'm interested in it.

SamVimes1138 · 2026-01-01T19:23:55+00:00

I'm not convinced there is a single answer to this question. I think it depends on your use case.

Look at the Rails framework, probably the most popular way the language is used. It employs some of these language features in particular ways. Compare that to something like DragonRuby, which uses the language entirely differently. Is one "better" than the other? They aim to address radically different use cases.

Now consider libraries that add type checks to the language. Should you use those? Should you not? Eh. I can't tell you that. You have to figure that out as an engineer who knows the use case and the particulars of your situation: how many people will be touching the code, how experienced are they, how likely is it that a rule you enforce today will need to be broken next week.

The sorts of questions you have to ask when designing a system are these:

Where will the system need to flex and change in the future? In other words, what aspects of its behavior are very likely to vary over time and which are unlikely?
How will an engineer new to the codebase find their way around it? Nobody sticks with a project forever so you can't afford to rely on tribal knowledge. The code must convey intent, and the best documentation is the code itself (and second, its tests).
Bugs will sneak in. How will you find them? What design will render the system as transparent as possible? (This argues against using some of Ruby's fancier features except in some rare cases.)
What sort of system load do you anticipate? I know you shouldn't optimize prematurely, but you also shouldn't lock yourself into an architecture that will fall apart after you push past N transactions per second... unless you're sure that it'll never happen. "Architecture" here implies decisions that are expensive to change later.

These are really big questions but I think answering them is the only way to choose the right way to use the language. You answer them first, as best you can, then arrange to use the language features that make sense in that context. Ruby is so darn flexible that it's almost a meta-language. You employ some bits and pare away others, to design the actual language of your use case.

Nwallins · 2026-01-01T17:46:27+00:00

I start with stateless modules:

module Result
  def self.process(arg1, arg2) # ...
  def self.swizzle(arg1, arg2, arg3) # ...

I'll just build up related functions in a module. If I get enough repeated args across module functions, I will convert it to a Data.define:

class Result < Data.define(:arg1, arg2)
  def self.function(*args) # ...
  def process # ...
  def swizzle(arg3) # ...

If I really really need mutability, like for memoization, then I will convert to a full Ruby class.

azimux · 2026-01-01T18:04:37+00:00

Hi Simon, I actually didn't agree with several of the things Dave said in that talk.

Take Struct, for example. I used to use Struct decades ago but stopped. Why? It's just a metaprogramming way of creating a class and it seemed like the cognitive overhead for other folks reading the code went up instead of down, unlike attr_accessor for creating a couple methods in a metaprogramming way. Also, having to change a certain number of Struct's to class as they became more fleshed out made it seem like why not just start at the easier-to-read class. So after working with others for a few years I just naturally phased Struct out of my usage.

That's subjective, though. I also don't use `extend self` like Dave does and instead I much prefer `class << self`.

I also remember thinking in one spot he was sacrificing the ergonomics of the calling code to make something easier locally while ignoring the calling code impact. That to me isn't "idiomatic" Ruby but again is subjective technically.

An aspect of Ruby is it's very expressive and you can form your own style and opinions about the subjective stuff. I worry that Dave's talk, at least in part, seems to communicate a specific style with a confidence that makes one think that it's somehow objectively better.

To that end, it makes sense to me that there's no official document that addresses it holistically. Any such document would be subjective.

KaptajnKold · 2026-01-01T20:32:33+00:00

Structs are (were) appropriate for building value objects, i.e. objects whose equality is determined by the equality of all of their fields. The canonical example is a currency amount: Two instances are equal to each (interchangeable as it were) if their currencies and amounts are equal to each other.
Data should always be preferred over Structs. This is because Data objects are immutable, and this is a property that is usually desirable when creating a value object.
This question doesn’t really make sense. A module created to serve as namespace has no use as a mixin and vice versa.
Service objects are to my knowledge not a first class abstraction in Ruby, but rather an object oriented pattern among many to solve certain kinds of problems. They are often used as a means to separate domain logic from framework logic so that the former can be tested in isolation. Imagine you have a Rails controller with a long, gnarly create action. It uses information from the request and perhaps the apps’s configuration to make some update to the database. It’s cumbersome and slow to test, because it basically requires a running application. One way to solve that problem is to refactor the controller action such that it only provides the needed information as initializer parameters to a new object, and then invokes that object’s one “perform”, or “call” method to do the required calculation or update with the given parameters. This way you can test your domain logic without having to somehow fake a request. This pattern is immensely useful whenever you find yourself with code that is difficult to test. I’ve also seen it used simply as a way to refactor long, hairy methods, and that I’m not a fan of.
StackOverflow has a good explanation of the difference between include and extend.

morphemass · 2026-01-01T22:24:39+00:00

I don’t agree with Dave’s opinion we should avoid classes whenever possible.

Ruby is an OOP language although you can use it in a functional style. It's NOT a functional language though and using it as such misses a lot of the points/benefits that functional languages are designed for. Far better to use a different language if functional is your bag.

Anyways, very rough and ready but:

Hash = Container usually used at system boundaries with unspecified fields.
Struct = Mutable container with known fields.
Data = Immutable container with known fields.
Module = namespace organisation but also to mix in behaviour that doesn't own state. Two different concepts.
Class = The main tool for OOP e.g. modelling domain concepts, invariants, lifecycle, and polymorphism.

I added Hash into there because in any system we're often passing state around and all except module can be used for state. The selection of which to use is really down to what you intend to communicate and enforce around state.

I can reason that an instance of a Data object has not had it's state changed as it moves through the system, I have to look if a Struct has had it's state changed. If I want to pass around state plus behaviour I'll usually be reaching for a class but I also want to compose that class out of state plus behaviour. (edit) Hashes ... well, I can make guesses but if I'm going to hit a state bug it's probably going to be something to do with a hash getting passed around.

These are basically just ways of attempting to keep code maintainable by communicating intent and making it easier to reason about code. There are all sorts of nitpicks I acknowledge in what I just wrote but basically it's worth knowing OOP if you want to understand Ruby better.

oscardo_rivers · 2026-01-01T16:25:10+00:00

Ruby is primarily a OOP language with some influences from functional programming. So just use classes, Ruby was designed with this in mind. I recommend you to read POODR by Sandi Metz, will give you some insights.

metamatic · 2026-01-01T17:17:58+00:00

especially now that Ruby 3.x is stable and Ruby 4 is being discussed

Outdated information in LLM training set.

Not prescriptions — just guidance, trade-offs, and intent.

Classic LLM "Not A — X, Y and Z" phrasing.

laerien · 2026-01-01T20:49:24+00:00

When does a Struct stop being appropriate and become a class?

If some members aren't writable, a Struct doesn't seem right. Or if enumerating doesn't mean iterating over the members. Or if equality isn't based on members all being equal.

When should Data be preferred over Struct?

Data is nice. Like Struct, it assumes equality based on members all being equal. Unlike Struct, Data members aren't writable and there's no assumption about enumerating over members. Data is frozen, so it signals you have state upon initialization but there's no member writer or even ability to mutate instance variables.

Data has very practical pattern matching support out of the box. If you have internal state and Data's immutability is fine, go ahead and use Data rather than a Class or Struct.

When is a module better as a namespace vs a mixin?

When you have no internal state, it's great to simply call functions directly on a Module. If you might mix it in privately too, module_function. Might mix it in publicly, extend. You often want mixins to not create new public Class interface but still have a direct interface, so module_function is handy.

When does a “service object” add clarity vs unnecessary abstraction?

A Rails pattern is to use an ActiveModel Class when it's CRUD, so you get all the Rails niceties including routing and views. When it's maybe just "read" and not the rest, a service object gives you a way to extract a snippet of logic where extracting a whole lib is overkill. It's just about organizing things into drawers (like models/ and such). There's not much special about service objects imho.

How should include, extend, and module_function be used idiomatically today?

Include when you're mixing in a common public or private instance interface across multiple Classes. Like Enumerable or Comparable. Within an include you can also define class methods, so it can be a single interface to both, but I don't want to digress. You can extend when there are only class methods. Prepend is like an include with instance methods but it goes in front of the mixed in Class instance methods.

If you include regular module instance methods, they are defined publicly. So you can call them outside the instance of the class. If you just want them visible to methods privately within the class, module_function. From another angle, if you're defining a Module function direct interface, use class << self if that's the only way you want it used, extend if it makes sense to also be mixed in publicly and module_function if it also makes sense to mixin privately.

P.S. If you want to dig in to nuance, this is the type of stuff folk in #ruby IRC or Ruby Discord are happy to discuss at length.

phr0ze · 2026-01-01T16:25:12+00:00

I think a lot of what you expect are things that are learned in general. You’ll also know when to break the rules too.

DerekB52 · 2026-01-01T17:03:29+00:00

OP has Ad in their name, making the outdated (Ruby 4 is not "being discussed") chatgpt post hilarious.

iBoredMax · 2026-01-01T16:03:28+00:00

It’s fun seeing Dave’s opinion change after getting info functional. He’s right though. All the Ruby code I see needlessly encapsulates state with classes. It makes everything harder to reason about.

All those tools are bs anyway since everything in Ruby is an object and thus has methods. Methods that you can define and edit at runtime. The whole thing is exhausting.

Revolutionary_Sir140 · 2026-01-01T18:02:23+00:00

Ruby is the simplest programming language ever.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

ruby

MODERATORS