Member coercions note in README.md file

[jatap]

Hi people, nice gem, good job.

Following example in README.md, important note about member coercions section, tests are falling.

testing.rb

[...]

class Library
  include Virtus

  attribute :books, BookCollection[Book]
end

library = Library.new
library.books << { :title => 'Another Introduction to Virtus' }

testing_spec.rb

context 'admits typed member coercions' do
  let(:library) { Library.new }

  before :each do
    library.books << { title: 'Another Introduction to Virtus' }
  end

  it 'respects master type' do
    expect(library.books).to be_kind_of BookCollection
  end

  it 'respects element type' do
    expect(library.books.first).to be_kind_of Book
  end
end

In order to get pass it, a default value must be supplied.

class Library
  include Virtus

  attribute :books, BookCollection[Book], default: BookCollection.new
end

Desired or unexpected behaviour?.

Gemfile.lock Version: 0.5.5

[solnic]

@jatap it's fixed on master but I will leave this open as I'm now in the middle of a bigger refactoring. Once I'm done with it I will make sure there's no regressions and close this issue.

Thanks!

[solnic]

OK this is fixed in master for sure, closing

[jatap]

I will test it, thanks again.

[solnic]

Awesome. There are some changes in master that might break backward compatibility as I removed most of the attribute subclasses and changed how attributes get initialized but it should only affect you if you're relying on those classes (and you probably don't) or build attribute instances (and you probably don't). If, however, it breaks things for you please report that. I'm gonna add some tricks to keep 1.0.0 compatible with 0.5.x and add deprecation warnings.

On Sun, Sep 22, 2013 at 2:08 PM, Julio Antúnez Tarín notifications@github.com wrote:

I will test it, thanks again.

Reply to this email directly or view it on GitHub: https://github.com/solnic/virtus/issues/189#issuecomment-24880896

[jatap]

Thanks for advice, I will feedback any issue about new changes.

In my first attempt(future gem acts_as_metatags), I'm using this great library to handle configurations in a better way, instead of ActiveSupport::Configurable. Default values are the key.

[solnic]

Oh that’s cool. I guess you could use virtus with coercions turned off as it’s not needed in such use case (probably).

[jatap]

I agree, in a simple use case/scenario it does, coercions maybe not needed.

But in current project, IMHO, is better to separate concerns and create a more complex data type structure in order to follow good OOP rules (I'm still pretty novice in Ruby). I'm integrating some kind of nested tree domain logic with pg hstore(each model attribute has a configuration key) and, to clarify code, I think is better to use coercions to identify different levels inside master property.

[solnic]

Oh I see. Yeah it was just my wild guess without having any insights.

On Sun, Sep 22, 2013 at 3:12 PM, Julio Antúnez Tarín notifications@github.com wrote:

I agree, in a simple use case/scenario it does, coercions maybe not needed.

But in current project, IMHO, is better to separate concerns and create a more complex data type structure in order to follow good OOP rules (I'm still pretty novice in Ruby). I'm integrating some kind of nested tree domain logic with pg hstore(each model attribute has a configuration key) and, to clarify code, I think is better to use coercions to identify different levels inside master property.

Reply to this email directly or view it on GitHub: https://github.com/solnic/virtus/issues/189#issuecomment-24881772