Types.Constructor failing on Ruby 3.1 about dry-types HOT 8 OPEN

In this case, the docs should be updated. Thanks for filing the issue

from dry-types.

Can you point out where you found this class definition?

class User
  def initialize(name:)
    @name = name
  end
end

from dry-types.

Can you point out where you found this class definition?

class User
  def initialize(name:)
    @name = name
  end
end

The docs don't have it there but based on the example here, I think it is the User definition.

from dry-types.

I did it as a temporary fix:

module Types
  include Dry::Types(default: :strict)

  def self.Constructor(klass)
    # DryTypes Constructor doesn't support Ruby 3.1 initialization
    # this is temporary code to make it work.
    #
    # See more details at: https://github.com/dry-rb/dry-types/issues/459
    super { |item| klass.new(**item) }
  end
end

from dry-types.

The docs don't have it there but based on the example here, I think it is the User definition.

This assumption is wrong, Types.Constructor expects sequential arguments. The correct definition is

class User
  def initialize(attributes)
    @attributes = attributes
  end

  def name = @attributes.fetch(:name)
end

We should update the docs with a sample User definition.

from dry-types.

I did it as a temporary fix:

I would suggest using a different name

module Types
  include Dry::Types(default: :strict)

  def self.KwConstructor(klass)
    # DryTypes Constructor doesn't support Ruby 3.1 initialization
    # this is temporary code to make it work.
    #
    # See more details at: https://github.com/dry-rb/dry-types/issues/459
    super { |item| klass.new(**item) }
  end
end

but it's up to you.

from dry-types.

The docs don't have it there but based on the example here, I think it is the User definition.

This assumption is wrong, Types.Constructor expects sequential arguments. The correct definition is

class User
  def initialize(attributes)
    @attributes = attributes
  end

  def name = @attributes.fetch(:name)
end

We should update the docs with a sample User definition.

Hi @flash-gordon,

Thank you for your attention,

My case wasn't related to this User example, this example I copied from the original reported issue here

My case was using Dry Initializer like:

  class User
    extend Dry::Initializer[undefined: false]
    option :id, type: Types::Integer
  end

  class Delete
    extend Dry::Initializer[undefined: false]
    option :user, type: Types.Constructor(::User)
  end

  # and using it like:

  Delete.new(user: { id: 1 })
  
  # `block in __dry_initializer_initialize__': User: option 'id' is required (KeyError)

So using only Dry Gems and only in Ruby 3.1+, I'm having this issue, what is weird. It seems like a bug. Since everyone using Ruby before 3.1 on this way, will have this issue when upgrading to Ruby 3.1

from dry-types.

It's because dry-initializer uses keywords. Before 3.0 ruby was more permissive regarding passing hashes where keywords are expected. Once a clear separation was made in 3.0 it doesn't work magically anymore. I cannot see what dry-types or dry-initializer can/should do about that. Defining a custom constructor is a consistent and non-breaking solution.

To be honest, I'm trying to stay out of the subject, it is very-very-very likely if we dig deeper by trying to fix anything here we'll come up with more bugs. Also, performance may suffer.

from dry-types.