Use `#call` instead of `#perform`

[ersatzryan]

Interactor's primary public API method is the perform class method. Why perform? Good question. The answer is because we had to pick something.

• perform
• run
• call
• execute
• work

The suggestion has been made to alias all of these methods and leave it to personal preference. There are two problems with that suggestion:

1. Interactor's purpose is to provide convention around a simple pattern. To dilute the API with multiple approaches to its most basic function would weaken the convention.
2. While aliases may work on the class level from which the interactor is called, the developer still must define an instance method to describe the interactor's actual behavior. Aliasing an arbitrary number of methods in a way that can determine which method the developer actually defined (overwrote) muddies the waters and adds a great deal of complexity.

   Proposed Solution

On both the class level and the instance level, interactors will use the call method rather than perform, because… Ruby. The call method is a common Ruby convention for method objects. It also has nice symmetry with Ruby's procs and lambdas.

Fun argument here.

class SessionsController < ApplicationController
  def create
    AuthenticateUser.call(email: params[:email], password: params[:password])
  end
end

class AuthenticateUser
  include Interactor

  def call
    # TODO
  end
end

[errinlarsen]

:+1:

[trestrantham]

I am not in favor of using call specifically because it allows procs if for no other reason than I want Interactor to be dependably serializable. I also agree with @jasonroelofs's point from the fun argument.

[zmoazeni]

I was looking at the code to submit a PR for this. Do you want to keep around the perform! concept?

[laserlemon]

Yeah, I think call! is useful for running interactors in environments where failure should be loud, like in a background process.

[laserlemon]

Included in the v3 branch.