Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alternative syntax suggestions #13

Open
KelseyDH opened this issue Sep 6, 2019 · 4 comments
Open

Alternative syntax suggestions #13

KelseyDH opened this issue Sep 6, 2019 · 4 comments

Comments

@KelseyDH
Copy link

KelseyDH commented Sep 6, 2019

This is an impressive DSL and I really like how it flows. 😉 However, I have to admit I find the concepts of dam and outflows to be confusing terminology. I love the railway analogy, but as it applies to water I find it a bit confusing. The railway analogy is described as success and failure paths so ideally control flow language should invoke those concepts.

So when I think of what would be most human readable for handling problems, it would be language like on_breach, on_failure or on_error.

Likewise for assessing state, instead of outflow I quite like context which is becoming the idiomatic way we see it done in gems like Interactors.

Otherwise I love this DSL! Cheers!

@apneadiving
Copy link
Owner

Hi Kelsey,

thanks for the feedback :)
I can understand all this water analogy does not please all minds!

I would not compare outflow with context from Interactors. In Interactor the context is some shared object leaking from one class to the other (I wonder what happens if two interactors happen to name variables the same way).
outflow would rather be a local_context, only attached to one object. It can pass values to another outflow upon request, that's it.

waterfall is a mini-gem, 200-ish LOC, so it is pretty much flexible. Here is a bonus if you want to get rid of water-ish syntax ;)

class MyInteractor 
  include Waterfall

  alias :on_failure :on_dam
  alias :local_context :outflow
end

class MyService < MyInteractor
   # ...
end

Cheers!

@artsyca
Copy link

artsyca commented Sep 21, 2019

The concept is not unlike Promises in Javascript -- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise

Promise.all()
Promise.allSettled()
Promise.prototype.catch()
Promise.prototype.finally()
Promise.prototype.then()
Promise.race()
Promise.reject()
Promise.resolve()

@apneadiving
Copy link
Owner

@artsyca yes totally.
Yet there is a ruby gem called Promise and I prefer not to take the same naming as code is most of the time synchronous here

@artsyca
Copy link

artsyca commented Sep 25, 2019

No, let's not even go there -- the waterfall metaphor is lovely

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants