added operateOn to sugar.nim to give Nim the chaining mechanism it de…

[Araq]

…serves

[Araq]

I probably got it completely wrong but it's to start a discussion.

[treeform]

Is there an example on how to use it?

[Araq]

      var x = "yay"
      operateOn x:
        add "abc"
        add "efg"
      doAssert x == "yayabcefg"

      var a = 44
      operateOn a:
        += 4
        -= 5
      doAssert a == 43

[juancarlospaco]

What about chainOn for chaining on instead of operateOn ?. 🤔

[alehander92]

or just on? so you can : a.on.add(..).add(..) (and do the on: for +)

[juancarlospaco]

on is true also. 🤔

[zedeus]

on is too short imo, likely to clash with object fields or event systems. I'd prefer chainOn

[juancarlospaco]

chainOn is kind of self-explanatory and short. "which function does chain?. chainOn" 🙂

[ducdetronquito]

I found this proposal on the forum thanks to Araq.

What is the reasoning behind this sugar syntax ?
Is there some production code where something like a builder pattern is not enough to chain procedures ?

In a small web framework I am working on, I wanted to chain procedures to define callbacks for multiple HTTP methods on the same URL.

Example:

import phoon

var app = App()

app.route("/hacks")
    .get(
        proc (ctx: Context) {.async.} =
            ctx.response.body("I handle GET requests")
    )
    .patch(
        proc (ctx: Context) {.async.} =
            ctx.response.body("I handle PATCH requests")
    )
    .delete(
        proc (ctx: Context) {.async.} =
            ctx.response.body("I handle DELETE requests")
    )

And wit the sugar syntax, it would become:

import phoon
import sugar
var app = App()

var route = app.route("/hacks")
chainOn route:
    get(
        proc (ctx: Context) {.async.} =
            ctx.response.body("I handle GET requests")
    )
    .patch(
        proc (ctx: Context) {.async.} =
            ctx.response.body("I handle PATCH requests")
    )
    .delete(
        proc (ctx: Context) {.async.} =
            ctx.response.body("I handle DELETE requests")
    )

I am genuinely wondering if this sugar is worth it, but I would be glad to be proven wrong :)

[SolitudeSF]

builder pattern is an awful hack that compensates lack of such sugar

[treeform]

Your example is using returns (builder pattern) to return the same router over and over again. Many of us think this is not that good because it confuses returns which should return useful info with making the syntax look nice.

chainOn trying to fix this example:

var app = App()

var route = app.route("/hacks")
route.get(
  proc (ctx: Context) {.async.} =
    ctx.response.body("I handle GET requests")
)
route.patch(
  proc (ctx: Context) {.async.} =
    ctx.response.body("I handle PATCH requests")
)
route.delete(
  proc (ctx: Context) {.async.} =
    ctx.response.body("I handle DELETE requests")
)

[planetis-m]

...and it could be written as:

var route = app.route("/hacks")
operateOn(route):
  get:
    proc (ctx: Context) {.async.} =
      ctx.response.body("I handle GET requests")
  patch:
    proc (ctx: Context) {.async.} =
      ctx.response.body("I handle PATCH requests")
  delete:
    proc (ctx: Context) {.async.} =
      ctx.response.body("I handle DELETE requests"

Please ship it :D

[planetis-m]

How about turning assignments to fields?

There is also https://github.com/citycide/cascade which is more advanced but slightly different (it returns a type). Maybe include that macro to the stdlib? cc @citycide

[haltcase]

@B3liever

This does work similarly to cascade, for reference it'd be something like this:

import cascade

var app = App()

var route = cascade app.route("/hacks"):
  get(
    proc (ctx: Context) {.async.} =
      ctx.response.body("I handle GET requests")
  )

  patch(
    proc (ctx: Context) {.async.} =
      ctx.response.body("I handle PATCH requests")
  )

  delete(
    proc (ctx: Context) {.async.} =
      ctx.response.body("I handle DELETE requests")
  )

Though like you said, cascade supports more than just chaining.