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

Javascripton needs better optional parameter management #15

Open
azazel75 opened this issue Nov 22, 2016 · 0 comments
Open

Javascripton needs better optional parameter management #15

azazel75 opened this issue Nov 22, 2016 · 0 comments

Comments

@azazel75
Copy link
Collaborator

azazel75 commented Nov 22, 2016

Actually the parameter handling has the following restrictions:

  1. keyword arguments are translated to a destructuring object assignment at the end of the positional parameters list. This is the same for the keywords parameters accumulator which is translated to an object. This means that passing keywords on call is not positionally indifferent: all the preceding positional parameters have to be specified before the keywords.

  2. Because of the previous point, the positional parameters accumulator, the keywords parameters or the keywords accumulator cannot be specified ad the same time. The fact that the keywords container is also positional and the fact that at call time is impossible to distinguish between expected keywords and the others that should be put inside the keyword accumulator forbids that.

The solution to this can be found in something that is "rendered" at translation time only or something that is half rendered and half a runtime feature, but with additional computation cost.

The former may be the rendering a proxy function for every declared function that uses a pre-determined calling convention and the addition of this proxy to the main function object. For each call, render a diverted path that checks for the existence of the proxy and calls it.

The latter would be to render the addition of python-oriented signature metadata to each function and render (maybe optionally) calls to be proxied via an utility function that takes care of handling the parameters according to the exported function signature.

The first solution may clutter the sources with each proxy definition but may be quicker in terms of speed compared to the second solution which may produce cleaner sources but relies on more runtime calculations.

Any other idea?

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

No branches or pull requests

1 participant