Just realised that this is a valid API usage ```cl...

# ktor

[evkaky]

Just realised that this is a valid API usage

client.post("some-url") {
    method = HttpMethod.Get
}

Why is this API modelled the way that you can write method = HttpMethod.SomeMethod inside that lambda?
That only makes sense inside a generic client.request method, where you dynamically compose an entire request, including http method
But changing method makes absolutely no sense inside specific methods such as post, get and so on

I checked, this overriding doesn't even work, so if you write method = HttpMethod.Get inside a client.post() { , the effective http method is still going to be post.
But I wonder why is it even allowed to write such a weird construction

[gpopides]

It's because they all use the HttpRequestBuilder class for the dsl. So they have access to the same properties

[evkaky]

Yes, but that's an implementation detail, which can be changed.
And it doesn't explain why the team came up with such an API design decision.

As an end user of ktor client lib I was really surprised that such weird API usage is allowed.

[CLOVIS]

that's an implementation detail, which can be changed.

not easily 😕

They could have had a different DSL type when the method is already fixed (I do this kind of stuff with KtMongo using interface delegation, but that doesn't play well with inline methods).

However, migrating to something like that could only be done in a major version and it would probably break a lot of code now

[gpopides]

its one of the tradeoffs of dsls.

On the other hand for example you can have a common function to set up common headers and configure the request in general in a generic way.

If we would have a different builder per client method you can imagine that it could become hard to both use and maintain

[CLOVIS]

> If we would have a different builder per client method you can imagine that it could become hard to both use and maintain
No, you could have HttpRequestBuilder and HttpMethodRequestBuilder or some other naming convention.

But even if there was one DSL per method (which is what I'm doing with KtMongo), it's perfectly maintainable using interface delegation

[evkaky]

Curious if the team is considering the API

client.post {
    method = HttpMethod.Get
    //...
}

as something that they would like to reshape/reimplement a bit, so it becomes impossible to write this in some future versions of ktor

[CLOVIS]

The easy options are a runtime exception or an IntelliJ warning. Changing the API will lead to a bunch of breaking changes, so I doubt they'll do it

[evkaky]

> a runtime exception
That might violate one of their main principles: type safe DSLs that don't allow you to write incorrect/weird code.

And as always, you either break your language/library to keep it as modern/polished as possible, or you do not break anything, but the number of weird/bad design decisions is getting bigger and bigger over time.

My opinion is breaking changes to the win!!

[CLOVIS]

Right, but breaking changes also fracture the ecosystem, and in the Kotlin community we care a lot about compatibility

Anyway I'm not part of the team, but I would bet they won't change it

[CLOVIS]

If you want to be sure they see it, create an issue → youtrack.jetbrains.com/newIssue?project=KTOR
and link it here afterwards

[CLOVIS]

• Please do not ping or mention someone directly to get your questions answered, especially project owners, whether the project is Kotlin or other, unless they specifically indicate that you can.

kotlinlang.org/docs/slack-code-of-conduct.html#…

Don't worry, they'll see the message at some point. If you want to be sure they do, an issue is the right way

[evkaky]

oh, didn't know that, thanks. I deleted the direct mention

[Bruce Hamilton]

we're considering adding custom errors in the compiler plugin for things like this. I'll make a note of it 👀