Hi Joe
I followed your instructions and got it to compile (hoping it will run as
well). Thank you very much!
For others reading this, I have updated the gist with a new file
<https://gist.github.com/magnusart/0802295c0fafdf9b5028>.
But I did not quite follow along on statement:
> (A simpler alternative is to put a separate map in front of each input
> from a => Left(a) and b => Right(b), then a simple MergePreferred will
> suffice)
Could you please expand a bit more on what you would do and where you would
map?
/Magnus
Den onsdag 15 juli 2015 kl. 00:27:32 UTC+2 skrev Joe Edwards:
>
> Inlets are naturally Contravariant (an inlet that reads A can be viewed as
> an inlet that reads B <: A), but that breaks down slightly when you're
> viewing it 'from the other side' - as the Outlet of something else. Perhaps
> there should be a view of the Inlet which can be used in a merge which is
> actually covariant, IDK.
>
> You can, however, work around it by ignoring that little detail:
>
> State[Any](ReadPreferred[Nothing](p.right,
> p.left).asInstanceOf[ReadPreferred[Any]]) { ...
>
> Since Nothing is a common subclass of everything, the contravariance
> allows you to construct the ReadPreferred[Nothing]. Then you can just cast
> it to a ReadPreferred[Any] - Type Erasure means it will cast successfully
> (at runtime)!
>
> The main danger here is that something in the implementation changes and
> this sort of thing might give you a runtime exception somewhere inside the
> FlexiMergeImpl. Luckily the current implementation will not.
>
> The other thing you should note is that L & R are also erased by Type
> Erasure, so if you want to match on them you'll need to have a ClassTag in
> scope (e.g. [L : ClassTag, R : ClassTag])
>
>
> (A simpler alternative is to put a separate map in front of each input
> from a => Left(a) and b => Right(b), then a simple MergePreferred will
> suffice)
>
> On Tuesday, 14 July 2015 16:58:12 UTC+1, Magnus Andersson wrote:
>>
>> Sorry, post button pressed by mistake.
>>
>> Continued:
>> FlexiMerge only seems to be able to handle inlets of the same type. I
>> wish to have a preferred merge that accepts two inputs, L and R and then
>> produce Either[L,R]. I would use the read preferred.
>>
>> Why this limitation and how can I work around it? I have created a gist
>> that illustrates my problem
>> <https://gist.github.com/magnusart/0802295c0fafdf9b5028>.
>>
>> Any suggestions appreciated!
>> /Magnus
>>
>> Den tisdag 14 juli 2015 kl. 17:54:23 UTC+2 skrev Magnus Andersson:
>>>
>>> Hi
>>>
>>> I'm trying to build an EitherRoute and EitherMerge flows.
>>>
>>> I've completed the EitherRoute which has one inlet that accepts
>>> Either[L,R] and two outlets that produces either L or R.
>>>
>>> When I'm constructing the EitherMerge I run into problems.
>>>
>>
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
