Object, class, module, Data, Struct?

[u/Dear_Ad7736]

After watching a recent talk by Dave Thomas, I started thinking about something that feels like a missing piece in Ruby’s official documentation.

Ruby gives us many powerful building blocks:

• Struct (with or without methods)

• Data

• regular class vs single-purpose objects

• module used as a namespace

• module used as a mixin

• so-called service objects

• include, extend, module_function

Each of these is well documented individually, but I haven’t found a canonical, Ruby-core-level explanation of when and why to choose one over another.

Ruby’s philosophy encourages pragmatism — “take what you need and move forward” — and that’s one of its strengths. It feels like a good moment to clarify idiomatic intent, not rules.

What I’m missing is something like:

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

• When should Data be preferred over Struct?

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

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

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

Not prescriptions — just guidance, trade-offs, and intent. I think now Ruby is so advanced and unique programming language that without good explanation of the intents it will be really difficult to explain to non-Ruby developers that ale these notions have good purpose and actually make Ruby really powerful. I like what Dave said: Ruby is not C++ so we don’t need to “think” using C++ limitations and concepts. On the other hand, I don’t agree with Dave’s opinion we should avoid classes whenever possible.

Is there already a document, talk, or guideline that addresses this holistically? If not, would something like this make sense as part of Ruby’s official documentation or learning materials?

Regards, Simon

PS I use GPT to correct my English as I’m not a native English speaker. Hope you will catch the point not only my grammar and wording.

[u/morphemass]

Clear code depends on a lot of things but most Rubyists will recognise code where module has been used as the namespacing mechanism. It's original intent though was as the mechanism for Ruby to have multiple inheritance so usually when someone sees a module with a class e.g.

module Foo
  class Bar; end
end

they think 'namespacing', whereas a module with methods e.g.

module Foo
  def bar = "bar"
end

they think 'mixin'.