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

Disabling functions like print #12

Open
kotx opened this issue Apr 14, 2021 · 3 comments
Open

Disabling functions like print #12

kotx opened this issue Apr 14, 2021 · 3 comments

Comments

@kotx
Copy link

kotx commented Apr 14, 2021

It might not be good to allow anybody who can eval expressions to print to console. I would like a way to do this in fasteval rather than checking for "print(" in the input or something.

@likebike
Copy link
Owner

Great idea. One way this might be implemented is by enabling the specification of the output stream, during the 'eval' step. (Right now, it always uses stderr.) This would allow the program to capture the output, or send it to /dev/null, etc.

@likebike
Copy link
Owner

likebike commented Apr 14, 2021

I want to also mention that 'print' is a bit different than other functions. It has a special syntax and it is the only function that can receive String arguments. So there is probably no way to create a general "override" ability that works for all functions.

Originally, I did allow overriding of functions -- I would check the custom-defined namespace first and only use the built-in functions (like 'print' or 'cos') as a last resort. But as you can imagine, it was very slow to always be doing this kind of check. When I changed the priority of this library to focus on speed, I had to drop that feature.

One other possible way to achieve this would be a Cargo.toml "feature", so the developer could choose whether or not to enable 'print'.

@kotx
Copy link
Author

kotx commented Apr 14, 2021

One other possible way to achieve this would be a Cargo.toml "feature", so the developer could choose whether or not to enable 'print'.

This sounds good. It won't be as customizable, but seems easier to implement.

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

2 participants