mdedetrich commented on issue #2093:
URL: https://github.com/apache/pekko/issues/2093#issuecomment-3221961817

   > [@mdedetrich](https://github.com/mdedetrich) I would prefer that we keep 
the existing ActorSystem `def terminate(): Future[Terminated]`.
   
   Well the cleanest way to solve this issue would be to provide an API that 
accepts an `ActorSystem` as an argument, that way you would have a 
`pekko.scaladsl.actor.Terminate(actorSystem: ActorSystem)` which will return 
`Future[Terminated]` and you would have a 
pekko.actor.javadsl.Terminate(actorSystem: ActorSystem)` which will return a 
`CompletionStage[Terminated]`. 
   
   There are even more natural options than this, one is to make our current 
`ActorSystem` private/internal stable API, and create an `ActorSystem` in both 
the `javadsl` and `scaladsl` package that inherits the current `ActorSystem` 
and have all of the `Future` returning methods on the `scaladsl` Actor and all 
of the `CompletionStage` ones on the `javadsl` actor. Another alternative is to 
use the delegate pattern which is also frequently used in pekko codebase.
   
   In conjunction you would also deprecate the current `def terminate(): 
Future[Terminated]` on `ActorSystem` in 1.2.x.
   
   I know that this is more work, however the counter argument to that is that 
the current `terminate()` method is clearly inconsistent with how the rest of 
the pekko API's are structured (where the api's are split between the 
`scaladsl` and `javadsl` packages respectively) and hence its current design 
seems to be a mistake/oversight?
   
   >  Can we just add `def terminateWithCompletionStage(): 
CompletionStage[Terminated]`?
   
   This would be out of place in terms of the rest of the pekko api's are 
designed.
   
   I have a bit of time at the end of the week, I can create a PR with one of 
the implementations I suggested (likely would be inheritence version since 
`ActorSystem` is abstract anyways and as a bonus these changes wouldn't break 
binary compatibility so they can be implemented in 1.2.x. We would howeer have 
to wait for the 1.2.x release a bit longer in such as a case as I would have to 
mark some current methods for deprecation


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to