Add Module#delegate_missing_to

[dhh]

Here's a common pattern if you want to build a decorator:

    class Partition
      def initialize(first_event)
        @events = [ first_event ]
      end

      def people
        if @events.first.detail.people.any?
          @events.collect { |e| Array(e.detail.people) }.flatten.uniq
        else
          @events.collect(&:creator).uniq
        end
      end

      private
        def respond_to_missing?(name, include_private = false)
          @events.respond_to?(name, include_private)
        end

        def method_missing(method, *args, &block)
          @events.send(method, *args, &block)
        end
    end

Would be nice to have it as:

    class Partition
      delegate_missing_to :@events

      def initialize(first_event)
        @events = [ first_event ]
      end

      def people
        if @events.first.detail.people.any?
          @events.collect { |e| Array(e.detail.people) }.flatten.uniq
        else
          @events.collect(&:creator).uniq
        end
      end
    end

[gsamokovarov]

I have a free afternoon, I can take a stab at this.

[rafaelfranca]

Is not this the same that SimpleDelegator does?

class Partition < SimpleDelegator
  def initialize(first_event)
    @events = [ first_event ]
    super(@events)
  end

  def people
    if @events.first.detail.people.any?
      @events.collect { |e| Array(e.detail.people) }.flatten.uniq
    else
      @events.collect(&:creator).uniq
    end
  end
end

[dhh]

I prefer not having to hijack the inheritance tree for such a simple feature. I find the use of inheritance + super odd as well. "delegate_missing_to" reveals intentions better and clearer.

On May 24, 2016, at 03:07, Rafael França notifications@github.com wrote:

This is not the same that SimpleDelegator does?

class Partition < SimpleDelegator
def initialize(first_event)
@events = [ first_event ]
super(@events)
end

  def people
    if @events.first.detail.people.any?
      @events.collect { |e| Array(e.detail.people) }.flatten.uniq
    else
      @events.collect(&:creator).uniq
    end
  end
end

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

[rafaelfranca]

👍. Agree it reveals the intention better.

[dhh]

I also like the parity with delegate_to. It feels like a natural extension
of it. Yes, the functionality is the same, but it's in a much nicer package.

On Tue, May 24, 2016 at 6:26 PM, Rafael França notifications@github.com
wrote:

👍. Agree it reveals the intention better.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#23824 (comment)

[connorjacobsen]

Why not just use the already existing delegate method? Then you can explicitly define the interface for the decorator instead of just passing anything through.

It makes the decorator interface well-defined, and far less permissive.

class Partition
  def initialize(first_event)
    @events = [ first_event ]
  end

  delegate :some_decorator_method, :another_decorator_method, to: :@events
end

[rafaelfranca]

There are cases where you want a permissive decorator, and for these cases I believe the proposed API is good.

[connorjacobsen]

Permissiveness aside, that functionality already exists in a much better way. The existing method forces the author to be explicit, better conveys intent, and provides an interface instead of just blanket allowing all of the things.

delegates_missing_to may reveal intention better than SimpleDelegator, but delegate on its own reveals intention far better than delegates_missing_to.

[rafaelfranca]

delegates_missing_to may reveal intention better than SimpleDelegator, but delegate on its own reveals intention far better than delegates_missing_to.

That is true. And now we have a spectrum of choices for people form the more permissive to the more explicit.

Even with the existing methods, people often use the method_missing + respond_to_missing? pattern. This new method is to make this common pattern easier.

You could agree that "explicit, better conveys intent, and provides an interface instead of just blanket allowing all of the things" is the best approach but people may think the best approach is what they want to use and Rails is just providing tools so people can choose.

#23930 was merged, so I'm closing this one, but this doesn't mean that the discussion is over. If you have more inputs to give, please let us know.