eval functions with panic safe implementation #79
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This requires a version bump in
ruby-sys
for the new eval methods and then theCargo.toml
here can be set to that version.The code works as is now but I have a few questions. Before those questions I'll explain that I've chosen to use
rb_eval_string_protect
forVM::eval
since it allows us to get a standardResult<AnyObject, c_int>
back and we won't need to worry about it crashing our program. Therb_eval_string
I added as an unsafeVM::eval_str
because any exceptions raised crash the program. So until we have exceptions implemented I figured this would be the safer Rust way to do it.My questions are whether we should have
VM::eval_str
at all since I've marked it as unsafe. Should theVM::eval
be enough and I remove the other method since we don't have exception handling? If so I would suppose the binding for that should go for now, or maybe#[allow(dead_code)]
?Of course once we have exceptions implemented then I would expect the
VM::eval
method to switch from therb_eval_string_protect
torb_eval_string
.Thinking out loud: But thinking about the way Rust works I believe that any time an exception is, or can be, raised then methods should return a
Result<AnyObject, Error>
and it would be nice forResult
to implement thetry_convert_to
directly on it. Errors can still be of typeAnyObject
but return types in general would make more sense as aResult
and just re-implement casting to theResult
typesOk
andErr
. Those are my thoughts on that.TODO
ruby-sys
update and updateCargo.toml