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

API enhancement #3

Closed
0x1793d1 opened this issue Jan 15, 2020 · 5 comments
Closed

API enhancement #3

0x1793d1 opened this issue Jan 15, 2020 · 5 comments

Comments

@0x1793d1
Copy link
Contributor

0x1793d1 commented Jan 15, 2020

Hi,

In order to improve the API, I suggest to apply these modifications to the crate :

  • Replace <S: Into<String>> with <P: AsRef<Path>> for path typed arguments (given that we can still use &str).
  • Change the return type of the packages optionals attributes functions from &str (and "" if missing) for Option<&str> (and None if missing).

If you want, I can do the modification in a PR.

@Morganamilo
Copy link
Member

To turn a string into a cstring. You need to append a null byte to the end. If you pass in a String then you can take ownership of it and just append the byte.

If the function took in a str, then you'd have still have to allocate a buffer so you can append a byte to it.

This is why I went for String.

The actual cstring API takes in a Into<Vec<u8>> though and not into<String>. I made that change to make the docs look more normal. And I don't see many people wanting to pass in byte arrays.

For the second point, do you mean things like, description and URL? In that case, I'm not really sure what to do. I tried to make this API stick as closely to alpm as possible. And in alpm, if desc is empty, the function alpm_pkg_get_desc() actually returns an empty string, not a null pointer.

But I don't think I'm really against changing it, as long as it's consistent and doesn't make the API too annoying to use with options everywhere.

@Morganamilo
Copy link
Member

For Path specifically, it's even worse. As Path is backed by OsString, the actual data stored is OS dependant, and the alpm functions expect a regular char*, so if we did take in a Path, we'd have to convert it back to the format alpm expects.

@0x1793d1
Copy link
Contributor Author

OK, maybe it's more tricky than I thought. This is just because I use Paths when manipulating files.

I will probably use path.as_ref().to_owned().display().to_string() to convert my path.

For the second point, I think it's always easier with options given that you can do unwrap_or andok_or to manage the result.

E.g., I want to return an error when the architecture field is missing. In this situation I could do:

let arch = pkg.arch().ok_or(MyErrorType::MissingField)?;

Or if I want the same behaviour as now:

let arch = pkg.arch().unwrap_or("");

@Morganamilo
Copy link
Member

I'm fine with making arch, desc, etc Options.

With the path stuff. The reason you howe to call . display() and can't just convert it to a string is that a path may contain not unicode so the conversion is lossy.

Thin is fine for displaying. But if you actually want to use the file then it may end up opening a different fine. Even if the chances are very low.

@0x1793d1
Copy link
Contributor Author

OK! I'll do the modification ASAP.
Regarding the path stuff: another way to do is to use path.to_str().
sdl2_image use this, sqlite too.

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