Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bikeshed the api traits / structs and function names #320

Open
o0Ignition0o opened this issue Apr 7, 2021 · 3 comments
Open

Bikeshed the api traits / structs and function names #320

o0Ignition0o opened this issue Apr 7, 2021 · 3 comments

Comments

@o0Ignition0o
Copy link
Contributor

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 ? :)

@vertexclique
Copy link
Member

At the time when this project first established, I wanted to use process pid for addressing async closures. Then onwards, I see that people wants to address content and it evolved to Akka's children model https://doc.akka.io/japi/akka/current/akka/actor/dungeon/Children.html

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.

@timClicks
Copy link

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"

@vertexclique
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants