Would
children = [
FootbalEngine.process_spec(file_path)
]
opts = [strategy: :one_for_one, name: FootbalInterface.Supervisor]
Supervisor.start_link(children, opts)
make you happier?
peerreynders
0
Fl4m3Ph03n1x
@LostKobrakai made the same suggestion, which I very much enjoyed. Safe to say it is the solution winning the most traction.
I just don’t quite get if I learned Dave’s lesson well enough, so I was wondering how he, according to his philosophy, would attack the issue.
Now I am thankful for his reply, but I am having trouble correctly interpreting it. Do you think my interpretation of his post is correct?
Also, thanks for the supervisor explanation, I appreciate it!
0
peerreynders
You’re asking me to interpret two things
- pragdave’s statement
- AND your interpretation
My impression is that it is seen as a acceptable engineering tradeoff to expose implementation details for the purpose supervision configuration given that it is not linked to the run-time behaviour of the process (the “server’s API”).
That being said I’ve run across examples in Erlang source code where functions were being used to “help” assemble child specs or for the purpose of hiding the implementation details of those child specs (which can still be subject to modification before they are passed to the supervisor for configuration).
In the past I’ve felt a bit odd about the “spread of responsibilities” of the functions in the GenServer (or gen_server) callbacks:
handle_call/3,handle_cast/2,handle_info/2seem to be the functions that relate directly to being a server.- The others seems to be more oriented towards OTP life cycle management.
Now in OO it wouldn’t be uncommon to have a separate lifecycle interface and a separate behaviour interface and have the objects of a class implement both at the same time.
However even in OO there is a similar tension between the constructor and the rest of the class. The constructor is concerned with building the thing while the rest is concerned with being the thing.
So in the end mixing life cycle concerns with run-time concerns in the same callback module doesn’t really seem all that odd in relation to processes.
0
rvirding
Creator of Erlang
I find that the interface part is generally quite small as all the functions generally do is just send of a request most of the code is in the callbacks. Separating them doesn’t give you that much. Also the interface calls and the code in the callbacks are very closely linked so they fir well together in the same module.
Now, of course, sometimes the implementation of the callbacks can result in quite a lot of code so breaking some of it out into a separate library module is a reasonable thing to do but doing that as a rule does not seem right. And finding a reasonable divide is often not that easy.
4
mindriot
I think the C# feature you are thinking of is #region. While I wouldn’t advocate cramming all kinds of things in the same file, it might be worth also considering why this is actually a problem. I think there is a bit of a difference between doing this in an OO world vs a functional world. Some reasons why you would work hard to extract anything you possibly can include:
• Reducing the size of the things you have to reason about as a whole (which is a class mainly due to the amount of mutation that is or can be happening)
• increasing reuse opportunity by being able to use the extracted code in a different context
• increasing composition options by being able to configure more easily how extracted components are combined via IOC or similar.
Having regions in a class is a strong indicator that you can improve any/all of the above factors and due to those reasons we often find ourselves taking any opportunity to separate anything even if it might make more sense not to in the absence of reasons created by the language constructs.
I’m not sure what the answer to your original question really is or where that should really land (especially since you are looking for a particular persons approach and there are good answers here already), however I would probably rethink the relevance of the region story and reconsider how many of the issues that drive that notion in C# are real problems that should force us to move things into another file when already our units of reasoning, reuse and composition are smaller.
2