talpr-50-flow-tagger #52
Conversation
Fix FocusedFlowOps.focus types Test FocusedFlow Remove unnecessary @uncheckedVariance
| setHandler(inTup, new InHandler { | ||
| override def onPush(): Unit = { | ||
| val (cur, in) = grab(inTup) | ||
| curr = cur |
There was a problem hiding this comment.
Let's make it passed in which value we pick :-)
This would be doable via magnet actually hm hm.
There was a problem hiding this comment.
Actually going with raw, sbt-boilerplate generated ones would be enough it seems,
and it also seems we do need a custom type, SubFlow won't do hm.
General idea would be:
// need to generate for 22-arity
implicit final class Focus2OnSource[+T1, +T2, +M](s: Source[(T1, T2), M]) {
import TupleGet._
def focus[T, TT1, TT2]( // fix variance
get: Tuple2[T1, T2] => T,
set: Tuple2[T1, T2] => T => Tuple2[TT1, TT2]): impl.SubFlowImpl[T, T, M, scaladsl.Source[Out, M]#Repr, scaladsl.RunnableGraph[M]] = ???
}
Source.single("" -> 12)
.focus(get = t => t._1,
set = t => v => t.copy(_1 = v))And instead of the SubFlow we'd need a custom type there it seems though – so yeah FocusedSource indeed so we have the type to unfocus.
Would you be able to give it a shot towards n-arity? Then it would be really awesome and useful I think
There was a problem hiding this comment.
@ktoso
So this brings up a couple of related questions:
- If the user has to provide the 'get' and 'set' mappings, then why limit it to tuples?
- If it is limited to tuples, then wouldn't it be better to generate methods like focus_1, focus_2,... ?
- What happens if the output of the flow is a different type from the input?
Originally I thought about having the user to provide the functions when calling focus/unfocus, but that made the API really cluttered and I don't think it saved too much (considering that the user can just add a 'map' themselves).
So what I'm trying to say is, I'll gladly try to make it work for larger tuples, but I'm not sure whether it really adds much.
There was a problem hiding this comment.
This is why I mentioned Lenses. They are basically reified getters/setters for immutable data. While it probably needs some good lense library (I think shapeless have them) they could work nicely. It is Scala only of course.
|
Very fun, hope to see the full thing soon :) |
|
On the side: one fun idea in a similar vein would be to accept Lenses to "project-down" a stream. Then you would be able to handle any n-to-n streams, filtering, mapConcatting or whatever on types, given that there is a Lens for it. eg. |
| def focus = new FocusedFlow(BidiFlow.fromFlowsMat(from, Flow[In])(Keep.left)) | ||
| } | ||
|
|
||
| def main(args: Array[String]): Unit = { |
There was a problem hiding this comment.
what about this main method? We would need unit tests instead :)
There was a problem hiding this comment.
Of course, this is still a draft... ^_^
|
Hm, this approach seems to be dangerous to me. It works for filter, but I don't see how it can work for 1-to-n stages. Also, isn't this racy? I mean the unfocus part and the tag it applies. |
|
@drewhk Like I said in the original issue, this won't always work, but in many simple use-cases it can be very handy. |
|
I just investigate if we can make it work better. For example if not only via is overridden, but mapAsync to automatically remove then add the tag, it can work, too. |
|
Yeah, that could work. It would probably require unfocusing the stream first, doing the mapAsync, and focusing again, but I guess that wouldn't be that bad... |
|
This hasn't seen any activity for a very long time. |
FlowTagger (issue #50)