[ruby-core:95341] [Ruby master Misc#16157] What is the correct and *portable* way to do generic delegation?

[merch-redmine@jeremyevans.net]

Issue #16157 has been updated by jeremyevans0 (Jeremy Evans).


Eregon (Benoit Daloze) wrote:
> jeremyevans0 (Jeremy Evans) wrote:
> > It certainly could.  I believe the idea of removing it after Ruby 2.6 is EOL is that gems that work on supported Ruby versions could continue to have a single method definition.  That method definition may need to change if `ruby2_keywords` is removed, though.
> 
> As we've seen countless times on bug trackers of many gems, many gems need to support Ruby versions which are EOL'd, because many applications exist and are not updated to the latest Ruby on every release.
> In other words, I believe MRI version EOL is not a good deadline for this.
> After all, there are other distributions than MRI which might EOL at different times or explicitly support older Ruby versions.

That's a possible argument for keeping `ruby2_keywords` longer or indefinitely. :)

> I believe removing `ruby2_keywords` is going to break those gems if we recommend them to entirely rely on `ruby2_keywords`.
> And since currently nobody knows when `ruby2_keywords` would be removed, it's a time bomb that would need every such gem to change to fix it.
> I doubt anyone wants that.
> I'd bet most people would prefer a bit more verbose code that will work in the future than changing code for 2.7, knowing it will break again in the future.

Certainly people that want that can already write separate method definitions depending on Ruby version.

As a counterpoint, most popular gems are well maintained and many of those only aim for compatibility with supported Ruby versions.  So using `ruby2_keywords` when it is available and switching away from it if it is removed may be easier for them.

Gems that aren't maintained may have issues in Ruby 3 anyway, due to keyword argument separation. Do you expect there will be a high percentage of gems that are maintained enough to add `ruby2_keywords` but will not be maintained enough to switch if it is removed?

> Unless we never remove `ruby2_keywords`, but that doesn't make sense to me:
> * It's a workaround for compatibility, we should not leave it in forever.

This depends on how much you value compatibility with older versions.  If you want compatibility with older versions, and don't want to define separate methods per version, you would want to keep `ruby2_keywords` defined.

> * It is modifying the behavior of things like `*args` which is inconsistent with other methods using `*args` but not using `ruby2_keywords`, creating inconsistency.

It is true that it results in inconsistency, and can result in behavior changes far away from the method using `ruby2_keywords`.  This is one reason it should be explicit and not the default behavior as some other people have proposed.

> * We should encourage new code for Ruby 3.0+ to not use such a workaround, by simply not be able to use it.

Then you are forcing separate method definitions per version if you want to support Ruby 2.6 and 3.0.  `ruby2_keywords` is designed to avoid that.

> * It's slowing down every single call with a `*rest` argument and without explicit keywords.

I believe the slow down is insignificant compared to all the other processing going on (in CRuby).  If you have benchmark results that prove otherwise, I would like to review them.

> I think it's not a good idea to propose a migration path that we know will need to change again in the future.
>
> To the best of our abilities, I believe it is our responsibility to provide a clear replacement that will work in all future Ruby versions.
> So Rubyists don't need to modify their code a second time and they don't have to drop compatibility with Ruby < 3 at the same time as changing the code for the second time.

I think that is fair.  However, the best solution if we don't want to change again in the future is to support `ruby2_keywords` indefinitely.  Any other approach requires separate methods definitions depending on the version.

I should also point out that the `ruby2_keywords` approach is even better at backwards compatibility then your proposed separate method definitions, since it works probably back to at least 1.6, whereas with the separate method definitions, it only works as far back as 2.0 (since keyword arguments are a syntax error in Ruby <2).

----------------------------------------
Misc #16157: What is the correct and *portable* way to do generic delegation?
https://bugs.ruby-lang.org/issues/16157#change-82050

* Author: Dan0042 (Daniel DeLorme)
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
With the keyword argument changes in 2.7 we must now specify keyword arguments explicitly when doing generic delegation. But this change is not compatible with 2.6, where it adds an empty hash to the argument list of methods that do not need/accept keyword arguments.

To illustrate the problem:

```ruby
class ProxyWithoutKW < BasicObject
  def initialize(target)
    @target = target
  end
  def method_missing(*a, &b)
    @target.send(*a, &b)
  end
end

class ProxyWithKW < BasicObject
  def initialize(target)
    @target = target
  end
  def method_missing(*a, **o, &b)
    @target.send(*a, **o, &b)
  end
end

class Test
  def args(*a)   a  end
  def arg(a)     a  end
  def opts(**o)  o  end
end
                                          # 2.6        2.7              3.0
ProxyWithoutKW.new(Test.new).args(42)     # [42]       [42]             [42]        ok
ProxyWithoutKW.new(Test.new).arg(42)      # 42         42               42          ok
ProxyWithoutKW.new(Test.new).opts(k: 42)  # {:k=>42}   {:k=>42} +warn   [{:k=>42}]  incompatible with >= 2.7
ProxyWithKW.new(Test.new).args(42)        # [42, {}]   [42]             [42]        incompatible with <= 2.6
ProxyWithKW.new(Test.new).arg(42)         # error      42               42          incompatible with <= 2.6
ProxyWithKW.new(Test.new).opts(k: 42)     # {:k=>42}   {:k=>42} +warn   {:k=>42}    must ignore warning? cannot use pass_positional_hash in 2.6
```

I don't know how to solve this, so I'm asking for the **official** correct way to write portable delegation code. And by **portable** I mean code that can be used in gems that target ruby 2.6 and above.




-- 
https://bugs.ruby-lang.org/