Thank you for the questions, José. I think the child_spec could take arguments that are a merged form of both arguments to start_link and to the supervisor spec. How would it look like?
GenServer.child_spec(__MODULE__, arg: [arg], restart: transient, name: Foo) Of course the options could be passed from "upstream". The options don't clash in the current behaviours. Of course it's possible they would in some custom behaviour or a future core one, but I think it should be fairly easy to solve those conflict on a case-by-case basis. Starting without a supervisor is indeed a possible concern. That said, it's generally advised not to do this in regular code - the cases where starting a process outside of a supervision tree are rather rare and encountered by advanced users. Nothing is stopping them from defining the start_link function like we do today - but for majority of cases it's simply not needed, if not plain wrong to start processes outside of supervision tree. There remain two places where starting ad-hoc processes outside of supervision trees is common - tests and iex sessions. A per-test supervisor you proposed (and an iex session supervisor) with a helper function to start the "child spec" under it might be a good idea. It will also solve one of the issues with tests and asynchronous termination of linked processes. By making this supervisor an all_for_one supervisor, the current behaviour of test termination in case of process failure will be maintained. I don't see much difference (in usability) between: MyServer.start_link or start_child(MyServer) called from the test or iex. > You claim we will be able to get rid of start_link but I don't think that's > true, at least not for abstractions such as GenServer and Supervisor. How > does that impact your proposal? I think it is true. Let's see an example: here's the application from the mix & OTP tutorial refactored to take advantage of the proposal. No start_link required. I also added some comments to explain the code. https://github.com/michalmuskala/kv_umbrella/commit/62bc49d21bbb93fa4e926ad7f7f41388fc978f83 Additionally here are the tests refactored to take into account the start_child proposal: https://github.com/michalmuskala/kv_umbrella/commit/753680541f1384c6d756a6550fc55089c507818d > Finally you say there are no hidden defaults but everything you hide between > GenServer.child_spec is a hidden default. Someone will eventually have learn > about it when they need to write their own child_spec. Does it change > anything? You make a good point that "child_spec" will become a default. I admit, it will become a convention, as much as start_link is one right now. I think it still has merits, though. I also understand that because of the code reloading concerns we can't make the calls to "child_spec" explicit - it needs to be called inside the supervisor. It is my understanding that if the "child_spec" call is kept inside the supervisor, the code reloading will work perfectly fine. I might be missing something, though - code loading is a part of OTP I'm not terribly familiar with. Michał. -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/a5c06d40-5c0a-4ba1-be70-0f0606a1aa5d%40Spark. For more options, visit https://groups.google.com/d/optout.
