[ismaelct]

What do you think of the Rack interface?

Or ActiveRecord's query chaining?

ex. User.where(admin: true).joins(:account).order(id: :asc)

It's all versions of the same approach.

And yes all of the above _can_ complicate debugging, for sure. But so can most abstractions. Only use them if the specific problem they solve is bigger than the drawbacks.

[corytheboyd]

I think some abstractions are fine and warranted, even ones you yourself come up with. Rails is a framework consisting of tons of opinionated abstractions. We need mental models to grasp complicated, large codebases.

My point is more to think twice about adding your own, and after thinking twice about it, think about it ten more times. Most people using Rails will already have an understanding or mastery of the abstractions you mentioned, but that understanding guarantee drops off quick with third-party gems, and is a guaranteed no for custom in-house solutions.

[whstl]

Rack and query chaining are great for two different reasons.

Rack because it's simple.

Query chaining in things like AR is fine because it is mostly debuggable up to a reasonable point with things like to_sql, etc. Since the actual query only runs in the end, it is decoupled enough, and the "escape hatch" of Raw SQL is not really a leaky abstraction, is just the of the abstraction itself.

The problem with things like Trailblazer is that it intertwines itself too much with the business logic, so using breakpoints is very difficult. And its internals are also super complicated, not to mention people build even more complex abstractions on top of it (since it's a bit lacking). It works fine for toy examples but anything multi-layer deep ends up making it too difficult to debug and make sense of.

[graypegg]

To me, Rack and AR are scoped to a specific domain. HTTP request handling and database-backed models are naturally going to involve some internal noise since I don’t want to write a web server or a database interface layer. I want the things I don’t want to write to be called.

Here, this is closer to general purpose flow control. There isn’t really a library I wouldn’t want to write myself here. You show a lot of examples of things that could be accomplished by objects and messaging passing (“plain Ruby”) which might be preferable for some.

All in all though, it’s a really interesting idea! I still really like the Ruby community’s love of bending ruby to their will. (Even if I do think it can cause issues sometimes)

[ismaelct]

I tried to keep this as idiomatic to Ruby as possible. No meta-programming, no FP machinery like monads, etc. Little more to it than an array of objects and a reduce function. All plain Ruby in my book.

I wonder if just using "throw :halt" (like in AR callbacks, to halt callback chains) or an Enumerator with "raise StopIteration" (which would work) would throw people off a bit less, just on account of those things being more familiar.

[corytheboyd]

Eh, don’t let myself or others influence your library. You will know what’s best, and hacker news will mostly elicit lots of nitpicky reasons as to why you are wrong.

[ismaelct]

To be clear this is not a library. I'm just describing a pattern and a bare-bones implementation.