Structs: what are they and what are they good for?

At todays developer discussion in Boston we discussed Structs, both in C and in Ruby. What are they? How should we use them. My notes follow.

Structs in C:

Structs in C are defined entirely by the memory offset of the fields that they contain. They are immutable and make for great value objects. The Objective-C APIs use them quite a bit (Point, CGRect, Origin, etc). Structs support accessing attributes using dot sytnax (rect.origin.x) but this differs from the dot syntax recently added by Objective-C. On structs you are essentially hopping through memory pointers to access values whereas Objective-C dot syntax is message passing.

** Structs in Ruby:**

Structs in Ruby are nominally supposed to represent a similar concept: a container for a value. Equality == does behave as you would expect. They differ greatly in just about every other area, however. Consider the following:

Person = do
  def greet
    "hello #{}"
  • Ruby allows methods to be defined on structs. See the greet method.
  • Ruby allows structs to be initialized with fewer than the number of arguments the struct was declared with. For instance, you could do and Ruby wouldn’t complain until you tried to call greet which would greet you with a sweet NoMethodError.
  • Structs in Ruby are mutable. They have public attr accessors. = @another_user is just fine by Ruby.

** What’s an OpenStruct? **

An open struct is essentially syntactic sugar on top of a Hash. It gives you dot syntax access to the members of the hash. Consider:

derek = 'Derek') # => 'Derek'
derek.age # => nil
derek.age = 33
derek.age # => 33

Notice that my initial hash didn’t include an ‘age’ property, yet my OpenStruct didn’t blow up when I tried to access it. Further, I was able to set it just fine and then access it. I can add to an OpenStruct whenever I please. We played with this some in pry, which showed that derek.age is defined by OpenStruct as soon as a setter is called. Essentially, it’s handling method_missing for any setter methods and creating them on the fly. This is why OpenStructs (creating and adding methods to) clear Ruby’s method cache. That’s
probably not too important in the world of Rails, but it’s something to be aware of.

** What are Ruby structs good for? **

No one really wanted to speak in favor of Structs. Creating a struct is arguably more convenient than creating a class because you get initialize for free. As we discussed earlier, though, that initialize isn’t very picky.

We’ve seen Structs for delegators and value object. Delegators may be better served with SimpleDelegator. If you’d prefer to be more explicit about your API, consider just writing a class. Structs aren’t a great fit for any sort of enforceable value object for the reasons we discussed. Consider something like the values gem for these.

We also commonly see people inherit from That is: class Person < This adds an anonymous class to your inheritence tree with no advantage any of us could see. If you’re going to use a Struct, pass
it a block instead.

If you’re scripting, Struct and OpenStruct can be very handy. Use them as you see fit there, but in your application code? Just write initialize. That was our basic conclusion.


I’ve also been fiddling around with a library for an immutable version of Struct, with a few API differences.

  • All instances are frozen
  • All arguments are required, rather than defaulting nil
    • Nicer syntax for setting defaults than overriding initialize and calling super:
    • class Point <, :y).with_defaults(x: 0, y: 0)
  • No attr_writers
  • Changes happen via a copy method, which takes a hash of arguments to change:
    •, 2).copy(y: 3) # => #<Point x=1, y=3>
  • No square brackets nonsense or other fluff from Struct, just the constructor/getters, copy, hash, and equality methods.

The code’s a bit messy at this point, and it’s not quite production ready, but you can check it out here:

@seangriffin, your library is an intriguing idea for folks who want to build lightweight value objects. Hope this gets an eventual official release.

The attr_extas project is worth a thought, too:

I’ve found Structs useful when working with return values from APIs. In two different cases when working with the BalancedPayments API I have had success letting a struct stand in for an object that should have been returned. Here’s one pretty simple example:

class CreditCard < ActiveRecord::Base
  # Only owner is a company for now, but could need users to be owners 
  # like bank accounts in the future if we find a need to charge investors
  # fees via credit card
  belongs_to :owner, polymorphic: true

  validates :name, :balanced_uri, presence: true
  validates_uniqueness_of :owner_id, scope: :owner_type

  def get_balanced_card_details
    rescue Exception'Card', :error) do
        def brand; error; end
        def expiration_month; error; end
        def expiration_year; error; end
        def last_four; error; end
      end'Not Found')

I should probably be rescuing a specific exception there. But the nice thing about this is that my view code remains exactly the same regardless of whether or not the API returns a card or has an error. I can always call @credit_card.get_balanced_card_details.brand without having to do an inline rescue or any sort of conditional branching in the view.

If you extracted that struct to a proper class, it’d serve the very same purpose and leave your code simpler to read. It could handle the decision to return either the actual balance response or your struct (which sounds like a null object). Then get_balanced_card_details is a one-liner, with the switching logical all contained in a separately testable class.

1 Like

Yea, good point. I think I’ll explore that extraction. Thanks for the input!