Skip to content

Add output_extensions option to PrettyConfig#339

Closed
juntyr wants to merge 2 commits into
ron-rs:masterfrom
juntyr:pretty-output-extensions
Closed

Add output_extensions option to PrettyConfig#339
juntyr wants to merge 2 commits into
ron-rs:masterfrom
juntyr:pretty-output-extensions

Conversation

@juntyr

@juntyr juntyr commented Nov 17, 2021

Copy link
Copy Markdown
Member

This PR adds an extra on-by-default configuration option to PrettyConfig. When output_extensions is set to false, the serialized RON will not include the #![enable(EXTENSION)] attributes.

This would also be related to #281, i.e. for use cases where RON is used e.g. for a configuration file that is both produced and consumed by the same program, extensions could be automatically enabled on deserialization and removed on serialization to remove the overhead.

While programmatically enabling extensions is doable already (just insert the attribute-enabling string before the RON), disabling them is much harder as you would have to parse and match on the attributes' format.

  • I've included my change in CHANGELOG.md

@juntyr juntyr changed the title Add output_extensions option to PrettyConfig Add output_extensions option to PrettyConfig Nov 17, 2021
@juntyr juntyr marked this pull request as ready for review November 17, 2021 14:10
@juntyr

juntyr commented Nov 17, 2021

Copy link
Copy Markdown
Member Author

@torkleyy One last PR (for now) that adds a tiny bit of extra functionality. Due to its relation to #281 I'd be very interested if you think this is the correct design for this feature.

@torkleyy torkleyy left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I was a bit skeptical about this originally, but I think this is the best solution.

However, I think we should provide a safer API to make it less confusing and error prone. I was thinking something like this:

fn ron_options() {
    ron::Options::build().implicit_some().build()
}

let ron = ron_options();

let foo: Foo = ron.from_file("foo.ron")?;
ron.to_file("foo.ron")?; // same options used for deserialization and serialization
ron.to_file_pretty("foo.ron", PrettyConfig::default())?;

We should also make sure to provide such a code snippet as documentation and to explain that one has to use the same options for serialization and deserialization. I think doing all this cleanly might involve some breaking API changes, not sure.

Comment thread src/ser/mod.rs
self
}

/// Configures whether the extensions are included in the output as

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I think we should describe the use-case here and what to look out for (enabling the same extensions when deserializing).

@juntyr

juntyr commented Nov 18, 2021

Copy link
Copy Markdown
Member Author

I really like the design you are proposing here. Do you think it would be best to first implement this new API and then after that the functionality to turn off the extension outputting? I might make sense to give a nicer usage example.

@torkleyy

Copy link
Copy Markdown
Member

Yes, I think that would be the best approach @MomoLangenstein 👍

@juntyr

juntyr commented Nov 18, 2021

Copy link
Copy Markdown
Member Author

Yes, I think that would be the best approach @MomoLangenstein 👍

Ok, I'll write that up then (maybe tomorrow)

@juntyr juntyr marked this pull request as draft December 3, 2021 10:43
@juntyr

juntyr commented Dec 3, 2021

Copy link
Copy Markdown
Member Author

This PR will be superseded by #343 and closed once that is merged

@juntyr

juntyr commented Dec 3, 2021

Copy link
Copy Markdown
Member Author

With #343 this has now become obsolete

@juntyr juntyr closed this Dec 3, 2021
@juntyr juntyr deleted the pretty-output-extensions branch December 3, 2021 14:51
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

Successfully merging this pull request may close these issues.

2 participants