You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Dry::Transaction::Callable seems overly aggressive in its attempt to address a shift in the ruby language around hashes passed to methods. Within Callable is the following documentation on ruby_27_last_arg_hash?:
Ruby 2.7 gives a deprecation warning about passing a hash of parameters as the last argument to a method. Ruby 3.0 outright disallows it.
This isn't 100% true. The ruby documentation around converting arrays into arguments states (emphasis mine):
If the method accepts keyword arguments [...] Note that this behavior is currently deprecated and will emit a warning. This behavior will be removed in Ruby 3.0.
As far as I can tell, the emphasized portion is not accounted for in Dry::Transaction::Callable. This may not seem like a big deal, but from a behavior standpoint it turns calls into call-by-value instead of call-by-reference, which can lead to issues when side-effects are expected.
To Reproduce
require"dry-transaction"classTxnincludeDry::Transactionstep:do_somethingdefdo_something(input)input[:side_effect] *= 2Success()endendinput={side_effect: 1}Txn.new.call(input)puts"This should be 2 => #{input[:side_effect]}"
Expected behavior
In my example input should be passed without generating a copy, allowing any modifications to the hash to be seen outside of the transaction. Locally, I have put this patch in place to address the issue:
Describe the bug
Dry::Transaction::Callable
seems overly aggressive in its attempt to address a shift in the ruby language around hashes passed to methods. WithinCallable
is the following documentation onruby_27_last_arg_hash?
:This isn't 100% true. The ruby documentation around converting arrays into arguments states (emphasis mine):
As far as I can tell, the emphasized portion is not accounted for in
Dry::Transaction::Callable
. This may not seem like a big deal, but from a behavior standpoint it turns calls into call-by-value instead of call-by-reference, which can lead to issues when side-effects are expected.To Reproduce
Expected behavior
In my example
input
should be passed without generating a copy, allowing any modifications to the hash to be seen outside of the transaction. Locally, I have put this patch in place to address the issue:I won't argue that this is the right way to do this, but it seems to work for my situation.
My environment
The text was updated successfully, but these errors were encountered: