naming of inter and outcome

[c-nv-s]

I had a browse through the documentation.
I know that naming things is quite difficult, however :
I was just curious as what made you choose the class names inter.x and outcome.x ?

to me it seemed to be a bit more intuitive if inter was just named web or http e.g. http.Request , http.Response .

and also if outcome was just named response e.g. response.Html( ... ) or response.Json( ... )

what do you think?
... and just to be clear, I appreciate all the hard work you've put into this project. It looks very good.

[reindert-vetter]

response/outcome

It is indeed always difficult to enter names. Giving a name in a Go environment is even more difficult. I would have preferred to use response. However, every time I used Confetti myself, I found it difficult. That's because I wouldn't be able to call a variable response. An example where I think the name of the variable is more important than the package name:

func (c AfterMiddleware) Handle(request inter.Request, next inter.Next) inter.Response {
    if ... {
        return outcome.Json("{}")
    }
    response := next(request)

    // Perform action

    return response
}

If I had used response here as a package, I could not name the variable response.

web or http

The package of the interfaces does not have the same name as the package name of the struct because you often have a conflict when you set up a struct and return an interface (with the same package name).

inter/contract

I have chosen not to use contract (while that is more of a standard), because the user can then use contract for its own custom interfaces.

All interfaces in package inter

In addition, all interfaces are in 1 package, because you want to prevent a circle import in Go. Placing all interfaces in 1 package is also better for autocomplete.

I had made it before as you indicate yourself, until I realized that I was fighting against the "more intuitive" names.

[c-nv-s]

that's fair. I understand your reasoning.