You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since we're focused on polishing the APIs at the moment, it's a great time to try to find names for our APIs that fit.
The main names we could bikeshed can be Children / Child | Supervisor | Distributor | MessageHandler
Given the project name uses wording that can be found in a military / defense context, refering to Children as Platoon (or maybe a Squad / Crew ?) was suggested. A child could be a Trooper or so?
Any thoughts ? :)
The text was updated successfully, but these errors were encountered:
Then we can address multiple actors with asterisk under the same group like "supervisor::*" will give all the async closures run with lightprocs (which we call processes) to be addressable all at once. This doesn't exist in Erlang obviously but that's where we diverge to create a better usage. So then children was born into it's current form.
Where possible, I would avoid using a plural for a struct name, e.g. Children. It creates mental friction for people learning the API because it leads to sentences that are grammatically incorrect, e.g. "a Children" and "two Children's"
I saw that too, we can get rid of that construct and leave redundancy to users directly in condition-controlled loops. I also don't like it in the current form, I agree.
Since we're focused on polishing the APIs at the moment, it's a great time to try to find names for our APIs that fit.
The main names we could bikeshed can be
Children
/Child
|Supervisor
|Distributor
|MessageHandler
Given the project name uses wording that can be found in a military / defense context, refering to
Children
asPlatoon
(or maybe aSquad
/Crew
?) was suggested. A child could be aTrooper
or so?Any thoughts ? :)
The text was updated successfully, but these errors were encountered: