dry-initializer
dry-initializer copied to clipboard
dry-rb
Does the check for unknown positional parameters work?
Hi,
thank you for this useful gem! I have one question about the design choice of how to generate the constructor of the object.
https://github.com/dry-rb/dry-initializer/blob/3167b5aee1d093886fe02448901db5a851f74d7b/lib/dry/initializer/builders/signature.rb#L8-L10
Why is the '*' included in the parameter list? Wouldn't that just match all positional arguments regardless of whether they are defined or not?
@kfischer-okarin Hi
You are right, the gem does not check the number of params, but just ignores the unknown ones.
This was made by design, because at the moment I got no good solution for adding stars (I mean both * and **) into the DSL. Now the migration to stricter checks is possible in theory, but this decision would cause a huge backward-incompatibility, so I would prefer not to make the change.
I see... I was just asking since it seems to contradict an intuitive reading of the documentation ( https://dry-rb.org/gems/dry-initializer/options-tolerance/ ). So it would maybe be good to add a section about this behaviour....
About the strict parameters..
How about parametrizing the module (builder) and adding parameters strict checking parameters for this? like... For the Container version this would work out of the box as in
include Dry::Initializer.define(allow_unknown_params: false) -> do
...
end
Though I'm not sure what would be an backcompatible way for the normal extend version. Maybe a something like.
extend Dry::Initializer.with_options(allow_unknown_params: false)
just bumped in this myself as well. Should the documentation be updated to correctly reflect the fact that positional arguments are not strict? Right now it says the following:
By default the initializer is strict for params (positional arguments), expecting them to be defined explicitly.
which doesn't seem to be case. As the current real behaviour is different from Ruby's own behaviour, I think it's worth documenting this correctly.
Does the much stricter Ruby behavior around handling args and keyword args make it simpler for us to enforce the same in the gem?
