Replace PathBuf to AsRef<Path> in the Engine file API
I also tested the changes with the following code:
#[cfg(test)]
mod test {
use super::*;
use std::path::PathBuf;
#[test]
fn test_replace_path_buf() {
let engine = Engine::new();
let mut scope = Scope::new();
let ast = engine.compile_file(Path::new("script.rhai"));
let ast = engine.compile_file(PathBuf::from("script.rhai"));
let ast = engine.compile_file("script.rhai");
let ast = engine.compile_file("script.rhai");
let ast = engine.compile_file_with_scope(&mut scope, Path::new("script.rhai"));
let ast = engine.compile_file_with_scope(&mut scope, PathBuf::from("script.rhai"));
let ast = engine.compile_file_with_scope(&mut scope, String::from("script.rhai"));
let ast = engine.compile_file_with_scope(&mut scope, "script.rhai");
let res = engine.eval_file::<i64>(Path::new("script.rhai"));
let res = engine.eval_file::<i64>(PathBuf::from("script.rhai"));
let res = engine.eval_file::<i64>(String::from("script.rhai"));
let res = engine.eval_file::<i64>("script.rhai");
let res = engine.eval_file_with_scope::<i64>(&mut scope, Path::new("script.rhai"));
let res = engine.eval_file_with_scope::<i64>(&mut scope, PathBuf::from("script.rhai"));
let res = engine.eval_file_with_scope::<i64>(&mut scope, String::from("script.rhai"));
let res = engine.eval_file_with_scope::<i64>(&mut scope, "script.rhai");
let res = engine.run_file(Path::new("script.rhai"));
let res = engine.run_file(PathBuf::from("script.rhai"));
let res = engine.run_file(String::from("script.rhai"));
let res = engine.run_file("script.rhai");
let res = engine.run_file_with_scope(&mut scope, Path::new("script.rhai"));
let res = engine.run_file_with_scope(&mut scope, PathBuf::from("script.rhai"));
let res = engine.run_file_with_scope(&mut scope, String::from("script.rhai"));
let res = engine.run_file_with_scope(&mut scope, "script.rhai");
}
}
I suppose it would break existing code that uses syntax like "script.rhai".into() ?
Yes, because now the compiler does not know which type we want to pass. But this can be easily fixed by removing ".into()".
Yes, because now the compiler does not know which type we want to pass. But this can be easily fixed by removing ".into()".
True, but that would break a lot of existing code since I recommended .into() in the examples.
I have been trying to find a way to do it generic while maintaining compatibility with .into()...
Yes, because now the compiler does not know which type we want to pass. But this can be easily fixed by removing ".into()".
True, but that would break a lot of existing code since I recommended
.into()in the examples.I have been trying to find a way to do it generic while maintaining compatibility with
.into()...
I think we can try to add a new type that implements both AsRef and Into traits for various types being passed. But isn't there any less complex way?
I think we can try to add a new type that implements both
AsRefandIntotraits for various types being passed. But isn't there any less complex way?
Yeah, I have been wondering about that also.
So unfortunately this will still be a major API-breaking change unless we can find ways to get rid of the Into error.
I think we can try to add a new type that implements both
AsRefandIntotraits for various types being passed. But isn't there any less complex way?Yeah, I have been wondering about that also.
So unfortunately this will still be a major API-breaking change unless we can find ways to get rid of the
Intoerror.
When is the release of the new major version planned?
When is the release of the new major version planned?
None has been planned so far... unless there is a good reason to introduce major API breaks which should mean some significant changes.