New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ideas on further API change #55
Comments
I like 2nd, 3d and 4th points. I like your general idea. |
|
|
@Horusiath |
With regards to composing
|
@Neftedollar most of the API will remain intact, while things like Effects and AskResult will probably be simplified, this won't be as noisy change as one would except in user code. I.e. while I want to get rid of Sample code: let ref = spawn system "my-actor" <| props(fun ctx ->
let rec loop () = actor {
let! msg = m.Receive ()
match msg with
| "stop" -> return Stop
| "unhandle" -> return Unhandled
| x ->
printfn "%s" x
return! loop ()
}
loop ()) This looks exactly like existing code however, |
I would like a I want to have something like this: let floater (ctx: Actor<int>) =
let rec loop() = actor {
let! i = ctx.Receive()
ctx.Sender() <! (float i)
return! loop()
}
loop()
let inter (ctx: Actor<int>) =
let f = spawnAnonymous ctx (props floater)
let rec loop() = actor {
match! ctx.ReceiveAny() with // should return obj
| :? int as i -> f <! i
| :? float as flt -> printfn "Received a float: %f" flt
return! loop()
}
loop() So, the actor still only accepts |
There are several ideas I have on potential changes concerning current API, some of them are breaking changes:
unit
return may be enough.AskResult<>
: by default we should be able to interop with ask pattern just by usinglet! response = ref <? request
and not having to unwrap the code each time if not necessary. If someone wants to have it presented in form of an object, he could use try pattern linelet 'try block = try Success <| block() with e -> Failure e
.async { ... }
computation expression. The idea here is to be able to define actor not only fromactor { ... }
but directly from async look as well.In general I'd like to reduce a footprint of Akkling API in user code in a way that user could potentially define his/her domain logic with minimal dependencies to Akka.NET/Akkling libraries.
The text was updated successfully, but these errors were encountered: