Recommended way to deal with non-string values

[DannyBen]

I am wondering what would be the proper way of dealing with non-string attributes, for example, numeric.

I would like to have the actual object's method return the proper type. Considering this object:

class Person < Ohm::Model
  attribute :age
end

I will always have to call #to_i on that age attribute.

So far the best idea I have is to create a shadow attribute:

class Person < Ohm::Model
  attribute :age_str

  def age
    age_str.to_i
  end

  def age=(val)
    age_str=val
  end
end

is there a cleaner approach?

[soveran]

Maybe Ohm::DataTypes could be the way to go for that use case.

[DannyBen]

Thank you. What I absolutely love about Ohm is the fact that there is nothing to learn. There are no attributes like default: value, or types or anything. This is what makes it great, and I guess, this is what keeps it alive due to the lower maintenance cost.

This ohm-contrib gem seems deep in the grave, being a fork with the last update in 2016. Plus the syntax is not pretty.

However, it is good to know that it is there - so I can look at its code if needed, and even better to know I have not missed anything.
I will probably implement these shadow methods - it is clean and maintainable.

[soveran]

Thanks you!

If you want to cast the values yourself, then you can use the second argument for the attribute declaration, which is what ohm-contrib uses internally for the Ohm::DataTypes extension:

class Option < Ohm::Model
  attribute :votes, lambda { |x| x.to_i }
end

option = Option.create :votes => 20
option.update(:votes => option.votes + 1)

assert_equal 21, option.votes

Passing that lambda {...} is enough for casting the values to integers. That sample comes from a test defined here.

Going back to your example, the code below should work:

class Person < Ohm::Model
  attribute :age, lambda { |x| x.to_i }
end

[DannyBen]

Oh! So this works without contrib?

attribute :age, lambda { |x| x.to_i }

If so, it is a very acceptable solution. Can be used for dates, and any custom object casting then!

I did not see it the README. Shouldn't it be mentioned in this section?

[soveran]

Absolutely! It was briefly documented here, but indeed it was an oversight not to mention that feature in the README, more precisely in the section you mentioned 😅

[DannyBen]

Wow - this is so cool.
I barely go visit the RubyDoc site - it is always harder to understand who wants what there (especially if it is not explicitly references in the README).

Thank you. This is improving the QoL of my Ohm based app.