Forem: Super Good

Anonymous Struct Literals Might Be Coming To Ruby

Jared Norman — Tue, 07 Jul 2020 15:38:44 +0000

There's been some really interesting discussion in the Ruby community about adding anonymous struct literals to the language. My Japanese isn't very good (I don't speak Japanese), but Koichi Sasada and Matz had a little Twitter exchange about the idea and that's now turned into a proposal on the Ruby tracker where there's been further discussion.

_ko1

@_ko1

@yukihiro_matz just idea なんですが、無名Structを簡単に作る仕組みをいれるのはどうでしょうか。同じキーセットなら、同じ無名 Struct が返るような感じで。

07:30 AM - 25 Jun 2020

3 14

What's a Struct?

Ruby provides Structs as a convenient way to create classes that group together a set of fields without forcing you to explicitly define a class with all the accessor methods.

For example, if you needed to pass around a representation of a dog but didn't need any additional behaviour you might do something like this:

[1] pry(main)> Dog = Struct.new(:name, :breed, :age)
=> Dog
[2] pry(main)> roxie = Dog.new("Roxie", "whippet-cross", 4)
=> #<struct Dog name="Roxie", breed="whippet-cross", age=4>
[3] pry(main)> roxie.name
=> "Roxie"
[4] pry(main)> roxie.breed
=> "whippet-cross"
[5] pry(main)> roxie.age
=> 4
[6] pry(main)> roxie.age = 5
=> 5
[7] pry(main)> roxie2 = Dog.new("Roxie", "whippet-cross", 5)
=> #<struct Dog name="Roxie", breed="whippet-cross", age=5>
[8] pry(main)> roxie == roxie2
=> true

Because instances of Structs are equal if their attributes are all equal, it makes them a great solution for defining value objects.

What does the proposal add?

There's some disagreement on the syntax, but the idea is to add a syntax for defining anonymous instances of Structs in-line. Today, you might write this:

roxie = Struct.new(:name, :breed).new(
  "Roxie",
  "whippet-cross"
)

With this proposal you'd be able to simply write something like this instead:

roxie = ${name: "Roxie", breed: "whippet-cross"}

This would create an instance of an anonymous Struct class without having to explicitly define and instantiate the class.

Why is that useful?

There are actually a number of benefits to this, but let's start with why anonymous Structs are useful regardless of the syntax.

Structs avoid typos

In Ruby we often use hashes for passing around things like configuration options and other structured data. Structs allow us to do this without allowing arbitrary properties.

In our dog example above, roxie.breeed = "pug" will cause an error because we spelled "breed" incorrectly and the Struct doesn't have a member called "breeed". If were using a Hash instead then we'd be able to accidentally assign roxie[:breeed] = "pug" without any errors, accidentally creating a new typoed key in the Hash.

There are many cases where you need arbitrary properties, but for those cases you can use OpenStruct or a Hash. When accepting configuration from a user or any other situation where you know the possible fields in advance Structs work great.

Anonymous Structs communicate intent

Writing code that communicates its own intent clearly is useful for helping future developers understand and modify that code. Using an anonymous Struct rather than a Hash or OpenStruct communicates to the person reading the code that the fields the object is defined with are the only fields that object supports.

Structs are simpler to access

This is admittedly a small improvement, but it's simpler to type roxie.breed than roxie[:breed]. In this example roxie doesn't represent an arbitrary mapping of keys to values, but a dog, so if we're following conventional object-oriented design practices, then roxie should be an object that responds to messages about itself.

Using Structs over Hashes also means that refactoring the code to use a real Class won't mean you need to change everywhere its data is accessed.

OpenStruct is slow

OpenStruct is another class in the standard library that provides the ability to create objects that are basically like Structs, but are "open" to creating new attributes like Hashes are.

This is extremely useful if you need to support arbitrary attributes on the object, but if you don't you're just opening yourself up to the same issue as using a Hash:

[1] pry(main)> roxie = OpenStruct.new(name: "Roxie", breed: "whippet-cross")
=> #<OpenStruct name="Roxie", breed="whippet-cross">
[2] pry(main)> roxie.breeed = "french bulldog"
=> "french bulldog"
[3] pry(main)> roxie
=> #<OpenStruct name="Roxie", breed="whippet-cross", breeed="french bulldog">

Additionally, while OpenStructs are definitely great when you need their "open" functionality, they are much slower than regular Structs. Koichi Sasada notes this in the performance section of his proposal.

But it says in the proposal that Hashes are faster!

One interesting detail that the proposal brings up is that Hashes are currently faster than Structs for this kind of usage. This is true, but Hashes have seen plenty of optimization because of how heavily we rely on them.

You would think that Structs would be faster than Hashes since their behaviour is simpler. Well, that's not the case but Koichi Sasada is confident that it could be the case with some optimization.

This proposal also enables a whole new optimization that is only briefly mentioned:

Thanks to this spec, we can specify anonymous Struct classes at compile time. We don't need to find or create Struct classes at runtime.

Because the attributes of the Structs is known at parse time rather than run time, it is possible to define the anonymous classes at compile time so that using this syntax incurs only the overhead of instantiating the anonymous class without having to define it too.

What does it mean for you?

For now, not much. We can't use this in our programs yet, but we are free to use anonymous Structs in our code without the special syntax. If you're creating value objects, want to limit the attributes on your object, or just want to make refactoring easier, this isn't a bad idea.

That said, keep an eye on this proposal. Switching to this syntax in your applications when it becomes available could have performance benefits, save on typos, and make your code clearer.

What do you think about this new syntax? Let me know on Twitter!

Working Around ActiveRecord Callbacks

Jared Norman — Tue, 10 Dec 2019 16:05:10 +0000

This article was original posted over here on the Super Good Software website.

Working on applications that overuse ActiveRecord callbacks can be painful. Saving or updating any given record might cause a cascade of API calls and business logic that's totally irrelevant to what you're trying accomplish. I've got a great trick for working around troublesome callbacks by allowing you to easily prevent them from running as needed.

I strongly believe that business logic shouldn't be implemented using ActiveRecord callbacks. Callbacks are great for data normalization and caching computed values. Sending e-mails, making API calls, and other side-effects should be implemented using some other programming pattern that untangles the logic from your persistence layer. Excessive use of callbacks leads to slow test suites, brittle systems, and unintended changes.

I run into many applications with complex third-party API integrations that are fueled by these cascades of after_save, after_create, and after_commit callbacks and are difficult to understand and debug. Ideally I'd love to untangle these messes and pull out the business logic into classes that can easily be understood and tested separately from the persistence layer, but I don't always have the time to do that.

Imagine this situation: you've got an Address model with a before_save callback that fetches and sets the latitude and longitude for that address. You're on a deadline and don't have the time to refactor every location in the code where you create an address. The callback is also slowing down your test suite because it's making slow requests out to the geolocation API every time you create an address. What's more, you've found some locations in the app where you create addresses and already know the coordinates. In these scenarios you don't need to do the lookup, but the lookup is being performed anyway.

You could address the test suite speed issue by using something like VCR, but with a few hundred tests creating addresses, that'll generate a ton of cassettes and doesn't solve the problem of the unnecessary API calls anyway.

There's a solution that alleviates both these problems with minimal effort. Let's say our address class looks like this:

class Address
  before_save :set_geolocation

  private

  def set_geolocation
    # Hit some API or something...
  end
end

What we can do is add an attr_accessor to control whether we want to perform geolocation and then condition the callback on that attribute. (attr_accessor :disable_geolocation is a handy shorthand for defining a disable_geolocation reader method and a disable_geolocation= writer method.)

class Address
  attr_accessor :disable_geolocation
  before_save :set_geolation, unless: :disable_geolocation

  private

  def set_geolocation
    # Hit some API or something...
  end
end

Now when updating or creating our addresses we can pass in this attribute to control whether geolocation is performed:

# This one will still cause geolocation:
address = Address.create(
  line1: "910 Government St",
  city: "Victoria",
  province: "British Columbia",
  country: "Canada"
)

# Here we prevent geolocation from running:
address.update(
  disable_geolocation: true,
  line1: "1328 Douglas St"
)

This works because ActiveRecord methods like update and create basically just assign the values you pass in, so it doesn't matter that disable_geolocation isn't backed by a database column. This also means that you can update your factory definitions:

FactoryBot.define do
  factory :address do
    name { "Jardo Namron" }
    sequence(:street_address) { |n| "#{n} Fake St." }
    city { "Vancouver" }
    province { "British Columbia" }
    country { "Canada" }

    disable_geolocation { true }
  end
end

When you create addresses using the factory you won't get geolocation by default, but can opt in as needed.

# No geolocation!
address1 = FactoryBot.create(:address)

# Yes geolocation!
address2 = FactoryBot.create(:address, disable_geolocation: false)

This pattern comes in really handy when you don't have the time to make the larger architectural changes to remove the offending callbacks altogether. It's definitely a hack; externally controlling an object's behaviour like this is an antipattern by my standards, but it extends well to more complex situations and cleanly addresses the immediate problem, so I hope you find it useful.