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

[FEAT] Support RemoteFunctions #49

Closed
sasial-dev opened this issue Jan 2, 2024 · 5 comments · Fixed by #54
Closed

[FEAT] Support RemoteFunctions #49

sasial-dev opened this issue Jan 2, 2024 · 5 comments · Fixed by #54
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@sasial-dev
Copy link
Collaborator

Describe your feature

Events should be able to return a value

Alternatives

Creating two events (one for each way)

Implementation Details

Careful decision will have to be made as to if we use RemoteEvents under-the-hood and then create a mock remotefunction-like interface in zap (so we don't yield the thread!).

@sasial-dev sasial-dev added the enhancement New feature or request label Jan 2, 2024
@jackdotink
Copy link
Member

Thinking about syntax for this:

funct name = {
	call: SingleAsync, -- SingleAsync or SingleSync
	args: f64, -- Ty
	rets: boolean -- Ty
}

Functions cannot be called from the server, only the client - so we can omit the from field.
Functions can only have one listener, so we only allow Single listeners.
Functions have different argument and return types, we we have two fields for them.

We also need to consider how we're going to handle yielding. Currently Zap does not yield, and ideally we have an option to allow users to choose between yield, promise-evaera, promise-nevermore, promise-redblox, and future. There might be other promise implementations, and we could support those as needed.

@sasial-dev
Copy link
Collaborator Author

Supporting different promise implimentations feels like a pain!
We could have yield/promise/future - but other than that I believe it's not worth it.
After all - Promises should be using the same API...

@jackdotink
Copy link
Member

that works, we can have a opt for the path to require promise impl from, and always use .new to construct them.

@sasial-dev
Copy link
Collaborator Author

And if futures use the same API - then you just pass it as a the path of promise?

@jackdotink
Copy link
Member

Futures do not use the same API

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

Successfully merging a pull request may close this issue.

2 participants