=str Switch the type parameter order of UnfoldResourceSource. #615
Conversation
|
I'm going to take some convincing that Pekko should go this way. Like it or not, most Pekko users are former or current Akka users. I don't see why making small adjustments to functions like this really helps. I favour keeping APIs including the type params as close as possible to Akka. New features would be absolutely great. Improving the internals of functions in a way that doesn't affect the API is great. |
|
The userfacing api did not change the type parameter order, and this is safe to compile both in source and binary, only be a problem when you use a reflection api to retrieve the typevariable's value. |
| * @tparam T - the element type | ||
| * @tparam R - the resource type | ||
| */ | ||
| def unfoldResource[T, R]( |
There was a problem hiding this comment.
@pjfanning Do you mean keep the typeparameter S here?
Even if the code compiles and bin compatibility is unaffected - there is the problem with the documentation and why our type params have different names from the Akka ones. In the end. how is R better than S. They are both unhelpful. Keeping the type param names as is and adding typeparam documentation would be more useful, in my opinion. |
|
@pjfanning https://doc.akka.io/api/akka/2.8/akka/stream/scaladsl/Flow.html#mapWithResource[R,T](create:()=>R)(f:(R,Out)=>T,close:R=>Option[T]):FlowOps.this.Repr[T] In this later, pr , |
| resumingMode = true | ||
| } | ||
| override def preStart(): Unit = { | ||
| resource = create() |
There was a problem hiding this comment.
It was named blockingStream, which leads to some kind of confusing.
Motivotion:
The type paramaeter
Sis really not great and the order is wrongNOTE:
The user facing api is untouched, as that will break code.
Result:
Clean code.
Expects a mima error?