Use `call` for method name in the organizer

[adomokos]

Right now, LS does not enforce a method name for organizers. You need to use the executed block in action, which generates the execute method, but there is no guideline for organizers. In fact, I've done this in the past:

FindsUser.by_id(id)

I am proposing a rule, that would warn the user to name the organizer's entry method like this:

FindsUser.by_id(id)
# Warning: The organizer should have a class method `call`.

And this warning wouldn't be triggered when the organizer has a call method.

FindsUser.call(id)

We began our work on "Orchestrators" ( see #65 for more details ), and we need to have a class method with a predetermined name an orchestrator can call in the call chain.

[mattr-]

With the organizer as the outward facing construct here, I dislike the idea of being required to use an organizer by doing a .call. It makes the API less expressive and removes intent that can be communicated with that method name.

That said, I do like .call as a hidden construct like execute is with actions and the executed macro, but I don't have a solution for what that would look like.

[adomokos]

Thanks for the feedback @mattr-!

In order to get orchestrators working properly, we must know what the method is called on the organizer. See the documentation for it here. We could also use metaprogramming to find the one and only (assuming you have one) public class method, but that's error prone.

I've gotten into the habit of using longer organizer names now. So, instead of calling PullsDataFromApi.by_id(x), I just call the organizer PullsDataFromApiById.call(x).

[mattr-]

Extending the name of the organizer might be useful here. Any worries about people confusing these with other types of callable objects and passing an object that responds to call that isn't an organizer?

[adomokos]

Not really. I'll just go with Ruby's duck typing: if it has a public call method, you can invoke it.

[adomokos]

Closing this, as #98 has been merged.