Proposal for DynamicSupervisor about gen_stage

[josevalim]

Dynamic supervisor is in master. What is left to be implemented is marked as TODO in the code.

[michalmuskala]

Given the DynamicSupervisor is similar to :simple_one_for_one, wouldn't it be better if it accepted just a single child specification instead of a list with just one element? It is my understanding that it doesn't make sense to pass multiple specs there.

[josevalim]

@michalmuskala yes, I was torn about this decision but I see benefits in keeping the return types the same for both supervisors (i.e. always a list).

[sasa1977]

What benefits do you see in using a list (which as far as I understand will always have to have exactly one element)?

Also, will we have the "module-less supervisor", i.e. something like: DynamicSupervisor.start_link(child_spec, supervisor_opts)?

[josevalim]

@sasa1977 callback specifications, functions like Supervisor.Spec, anything else that works on childspecs will always expect the same type.

And yes, the module-less supervisor will be there.

[sasa1977]

The only such function I see there would be Supervisor.Spec.supervise, which I don't think makes sense for dynamic supervisors anyway. Not only because it accepts multiple children, but also because it takes a strategy as an option (which doesn't make sense for dynamic supervisors). You'd again need conditionals in the docs to describe how is this used for static vs dynamic supervisor, so I'd say it's better to separate the two implementations. The dynamic one could then require a single child.

The remaining two functions can be shared between both supervisors, as they are not concerned with the child specification.

I'm still confused about "anything else that works on childspecs will always expect the same type". What else is out there?

[josevalim]

A strategy will still be required for dynamic supervisors. It will ship
only with :one_for_one but we may add others in the future.

If in a couple years we don't add another strategy, we can remove this
requirement. It is always better to start with such requirements because
removing them later on is backwards compatible. If we don't enforce a
strategy option now and add a new strategy in the future, we won't be able
to enforce the option, as it would be backwards incompatible, and we will
regret not being explicit today.

I don't have any examples today of other strategies we may add (if I did
this decision would be much easier ;)). It still does not change the fact
the strategy option will be required (for now).

José Valimwww.plataformatec.com.br
http://www.plataformatec.com.br/Founder and Director of R&D