Just my two cents, but if the change involves reimplementing the supervisor behaviour, I'm really not a fan - I have to say that neither of the proposals solves any problems I actually have, but that in and of itself isn't a reason to object, but re-implementing :supervisor seems like a huge change to make for something which (in my opinion) is almost entirely superficial.
José's proposal seems like the best of both worlds from my perspective, anything more invasive just makes the divide between Erlang and Elixir wider and more difficult to cross for many, and I still believe that the parity between the two languages is a strength, not a weakness. If there is a way to reduce boilerplate but still keep concepts trivially exportable between the two, then I'm all for it, but otherwise it just feels like the wrong direction to me. Paul On Thu, Feb 23, 2017 at 7:34 AM, José Valim <[email protected] > wrote: > Oh, I see. Let's see what James thinks about it although it comes with a > very big concern of reimplementing the Supervisor behaviour. > > > > *José Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Director of R&D > > On Thu, Feb 23, 2017 at 1:12 PM, Michał Muskała <[email protected]> wrote: > >> On 23 Feb 2017, 13:09 +0100, José Valim <[email protected]>, >> wrote: >> >> What if we had a custom supervisor implementation that would always call >>> child_spec before restarting? >>> >> >> It is the opposite, if the supervisor restarts, then it reloads the >> child_spec. The problem is all other scenarios where any of the modules in >> your system may change but the supervisor did not (because it didn't have >> to). Examples of this include: >> >> 1. When compiling a Phoenix a project in development, we would need to >> traverse your application tree and ask all supervisors to reload childspecs >> >> 2. When building a relup, the release needs to go through all supervisors >> and tell them to reload childspecs >> >> Another way to put it is that, in the same way our current >> worker/supervisor is broken because it moves the child_spec logic out of >> the supervisor, removing start_link will be broken because it moves the >> start_link logic inside the supervisor and outside of the supervised module. >> >> >> I'm proposing that the supervisor *always* reloads the child spec before >> restarting a child. That way the problem goes away in both examples you >> showed. >> >> 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/ms >> gid/elixir-lang-core/55932eea-667c-49d6-8de8-1cd263a61988%40Spark >> <https://groups.google.com/d/msgid/elixir-lang-core/55932eea-667c-49d6-8de8-1cd263a61988%40Spark?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- > 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/CAGnRm4JGLfSwKd%3DeSuMhW1MXJv_ > KhixfG6b88k6e%2B_K4SAWt8w%40mail.gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JGLfSwKd%3DeSuMhW1MXJv_KhixfG6b88k6e%2B_K4SAWt8w%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CAK%3D%2B-TvoSpQigew1814RGG0LnGmfFAeCBwai%2BJs7pNZZcsRVvA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
