Make path-based inputs generic of AsRef<Path>
#73
Conversation
This simplifies calling code from outside the library in various places; various components no longer need to be compelled or recollected into the exact typing that the input requires, but instead can be used in anything that can be treated as a path slice.
|
This isn't the absolutely most efficient use of the generics - likely if we tightened up the access modifiers a little bit there'd more a more natural place at which we canonicalise the typing / require ownership / whatever, but immediately this is just making the typing of the interface a little more Rust-y. The requirement to specify the type of the |
| if let Some(paths) = search_path_list { | ||
| for path in paths { | ||
| if let Some(full_path) = try_path(path.as_ref()) { | ||
| return full_path; | ||
| } | ||
| } | ||
| } else if let Some(paths) = search_paths() { | ||
| for path in paths { | ||
| if let Some(full_path) = try_path(path.as_ref()) { | ||
| return full_path; | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
This isn't ideal with collecting a generic from the user input but also hard-coding access to the environment, but it's well wrapped, and this way doesn't involve collecting a Vec from the environment if nothing's given.
|
Thanks. I thought the interface was too rigid. But I opted to get it done as quickly as possible.
On the other hand, it makes the call site more readable and understandable. Seeing things like
As I said, I was concentrating on getting file inclusion and error reporting working. Using the env variable was quick. But the more I think about it, the more I agree it doesn't belong in the bowels of the library. This is a bit junky, and it is propagated through calls: openqasm3_parser/crates/oq3_semantics/src/syntax_to_semantics.rs Lines 101 to 103 in 2d8e34f I imagine in the future, more information will need to be passed to I am not opposed to removing the environment variable stuff, depending on how it plays out. I don't see off the top of my head how a specification of a search path at a higher level can be propagated to the search for included files. (I mean without actually propagating it, which is what we want to remove!) |
|
At some point, I imagine the answer is that we'll want to wrap up a larger amount of configuration into some sort of |
This simplifies calling code from outside the library in various places; various components no longer need to be compelled or recollected into the exact typing that the input requires, but instead can be used in anything that can be treated as a path slice.
When calling from Qiskit side, it's quite inconvenient to re-collect everything I get natively as
stror whatever from Python space into an owningPathBuf, where it's already interpretable via reference into aPath-like (OsStringis a superset ofStringfor use in file-system access, andOsString: AsRef<Path>sincePathis give-or-take a wrapper around&OsStr(which in turn is toOsStringas&stris toString)).