Skip to content
This repository has been archived by the owner on Jul 22, 2023. It is now read-only.

Add writeNewModelAsset and writeNewPlaceAsset #40

Closed
wants to merge 12 commits into from
Closed

Add writeNewModelAsset and writeNewPlaceAsset #40

wants to merge 12 commits into from

Conversation

nezuo
Copy link
Contributor

@nezuo nezuo commented Apr 14, 2021

Pretty straightforward implementation. All options are not required except for the name option. The other ones default to "" or false. Technically, allowComments doesn't change any behavior for places, but I left it in there for future proofing? I can remove it if necessary.

Copy link
Contributor

@jeparlefrancais jeparlefrancais left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't forget to add an entry to the changelog 🙂 And documenting the new functions in the readme would be awesome too!

@nezuo
Copy link
Contributor Author

nezuo commented Apr 17, 2021

I don't have any good ideas on how to format the options parameter in the documentation. If anyone has any good ideas, let me know!

Copy link
Contributor

@jeparlefrancais jeparlefrancais left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other thing that is coming to my mind right now, shouldn't each of these functions return an asset id?

README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
@nezuo
Copy link
Contributor Author

nezuo commented Apr 18, 2021

Alright, they now return the asset id. I originally tried to combine writeExisting__Asset and writeNew___Asset to use the same function internally. Now that they have different return types, it might just be worth it to repeat code and separate the functions, let me know what I should do.

README.md Outdated Show resolved Hide resolved
Copy link
Contributor

@LPGhatguy LPGhatguy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly comments on Rust idioms.

Comment on lines 31 to 71
fn get_required_string_option(options: &Table, option: &str) -> rlua::Result<String> {
let value = options.get(option).map_err(rlua::Error::external)?;

match value {
Value::String(value) => Ok(value.to_str().map_err(rlua::Error::external)?.to_string()),
Value::Nil => Err(rlua::Error::external(format!(
"The option {} must be specified",
option
))),
_ => Err(rlua::Error::external(format!(
"The option {} must be a string",
option
))),
}
}

fn get_string_option(options: &Table, option: &str, default: &str) -> rlua::Result<String> {
let value = options.get(option).map_err(rlua::Error::external)?;

match value {
Value::String(value) => Ok(value.to_str().map_err(rlua::Error::external)?.to_string()),
Value::Nil => Ok(default.to_string()),
_ => Err(rlua::Error::external(format!(
"The option {} must be a string",
option
))),
}
}

fn get_bool_option(options: &Table, option: &str, default: bool) -> rlua::Result<bool> {
let value = options.get(option).map_err(rlua::Error::external)?;

match value {
Value::Boolean(value) => Ok(value),
Value::Nil => Ok(default),
_ => Err(rlua::Error::external(format!(
"The option {} must be a bool",
option
))),
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These functions feel pretty heavy! We should be able to write one generic function for required parameters and one for optional ones. We can leverage the FromLua trait to make this work for any type and avoid a lot of boilerplate.

Comment on lines 73 to 79
fn bool_into_query(boolean: bool) -> String {
if boolean {
String::from("True")
} else {
String::from("False")
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Usage of this should not be pervasive enough to warrant a function; we should be able to keep the bool-to-query stuff entirely inside the code that actually does HTTP requests.

context: Context<'_>,
lua_instance: LuaInstance,
asset_id: u64,
) -> rlua::Result<()> {
queries: &[(&str, &str)],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is the right interface here. We should instead accept a struct of known fields that are turned into the correct querystring parameters by this function.

Comment on lines 438 to 441
match Remodel::write_model_asset(context, lua_instance, asset_id, &[]) {
Ok(_) => Ok(()),
Err(error) => Err(rlua::Error::external(error)),
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function already returns an rlua::Result, we can just return the error here, or better yet, use Rust's ? operator.

Comment on lines 449 to 452
match Remodel::write_place_asset(context, lua_instance, asset_id, &[]) {
Ok(_) => Ok(()),
Err(error) => Err(rlua::Error::external(error)),
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here as in the other case. Matching here doesn't really make sense when we have ?.

buffer: Vec<u8>,
asset_id: u64,
queries: &[(&str, &str)],
) -> rlua::Result<String> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This return value should probably be a u64, not a string, since asset IDs are numbers.

let asset_id = response.headers().get("roblox-assetid");

match asset_id {
Some(asset_id) => Ok(String::from(asset_id.to_str().unwrap())),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know if we can unwrap here. We don't control this value, so whatever can cause to_str to not return a value might fail!

@nezuo nezuo requested a review from LPGhatguy April 23, 2021 23:02
context: Context<'lua>,
options: &Table<'lua>,
option: &str,
default: T,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's just make this function return an rlua::Result<Option<T>> instead of passing a default. Rust has lots of great features that let us easily fall back to a default that are more flexible than this. We can also merge it with get_required_option for the same reason!

@nezuo nezuo requested a review from LPGhatguy May 1, 2021 20:56
};

let description = get_option(context, &options, "description")?;
let description = match description {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For all of these, I think you want .unwrap_or_default() instead for succinctness.

@nezuo
Copy link
Contributor Author

nezuo commented Jun 16, 2022

Close in favor of #79

@nezuo nezuo closed this Jun 16, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants