Message cleanup #2234
Message cleanup #2234
Conversation
I'll rebase onto master once #2210 is merged. The diff here will also be quite messy until that happens |
Put the removed methods in Message/Request/Response Remove unused implicit parameters Deprecate and rename some methods to align naming
I think the appveyor failure is unrelated. |
This is nice. I mostly question the laziness. Would like to hear from others. |
def withHeaders(headers: Headers): Self = | ||
change(headers = headers) | ||
|
||
def withHeaders(headers: Header*): Self = |
rossabaker
Nov 2, 2018
Member
Is there a better naming idiom we could adopt here and avoid the overload? I've grown more hostile to those, but don't have a naming suggestion.
Is there a better naming idiom we could adopt here and avoid the overload? I've grown more hostile to those, but don't have a naming suggestion.
aeons
Nov 5, 2018
Author
Member
I don't have a better idea.
I don't have a better idea.
* Attempt to decode the [[Request]] and, if successful, execute the continuation to get a [[Response]]. | ||
* If decoding fails, an `UnprocessableEntity` [[Response]] is generated. | ||
*/ | ||
final def decode[A]( |
rossabaker
Nov 2, 2018
Member
I'm skeptical of the value of this and decodeStrict
, but more people use them than I realize. I don't know that I want to fight the deprecation battle for something so common, but I dislike having multiple ways to do it.
I'm skeptical of the value of this and decodeStrict
, but more people use them than I realize. I don't know that I want to fight the deprecation battle for something so common, but I dislike having multiple ways to do it.
aeons
Nov 5, 2018
Author
Member
I would be 👍 on deprecating it. I guess we can look at reports for it for the milestones as a gauge for how much it's used.
I would be
rossabaker
Nov 5, 2018
Member
Deprecation + scalafix is going to be a powerful combination for us for things that can be translated directly. It would be nice if the two start going together once the scalafix lands. I'm comfortable taking this on in a subsequent PR.
Deprecation + scalafix is going to be a powerful combination for us for things that can be translated directly. It would be nice if the two start going together once the scalafix lands. I'm comfortable taking this on in a subsequent PR.
Is there a point to having |
It can theoretically help with static optimizations, but the JVM is pretty smart about what's actually overridden. I would expect it to not make a practical difference at runtime, and it's a question of signaling intent. Here, I don't think it's a huge deal either way. |
|
Alright. To be consistent I've made all of them non-final. :) |
|
This builds on top of #2210, and should not be merged before that.
This PR does the following:
replaceAllHeaders
, pointing towithHeaders
instead. The other direction of this was done in 0.10, apparently. Currently, allwithX
methods replace theX
. For headers, we havewithHeaders
that replaces andputHeaders
that adds.withType
, which takes aMediaType
and just wraps it in aContent-Type
withContentTypeOption
, recommending to just do theOption.fold
in user codewithoutAttribute
andwithoutTrailerHeaders
to complement thewith
variantsdef
s intolazy val
sfilterHeaders
' scaladoc comment said that it would remove all headers that the predicate was true for, while doing the opposite. I have changed the comment to be correct and changedwithoutContentType
which depended on the behaviour described in the comment.Many of the methods in the
*Ops
traits werefinal
. I have kept that where it made sense, but I'm not sure it's needed. Can anyone clarify?Closes #2224