Open MostHated opened 3 years ago
Hey,
thanks for the question! This library does not contain any helpers for deserializing TOML into an arbitrary object or vice-versa. This choice was inspired by SimpleJSON to keep the overall size of the library smaller. As with SimpleJSON, this library simply provides helpers to access/write values more easily, so that accesses like table["foo"]["bar"]
where foo
nor bar
won't cause exceptions right away.
At the moment you would have to implement (de)serialization yourself, but I am considering extension methods for that.
I appreciate the reply. It seemed like that was the case, but I just wanted to be sure, so no worries. 👍
Late last night I decided to have a go at this to see if I could make it work by just passing in a class containing properties, as that is what I am using in my project at the moment. I started out making some basic attributes and just used a string and an int to test, but the results were promising, even if it ends up just being for my own use-case. I added several more types of test data and I am currently working my way through them to make sure I get the conversion working properly.
It didn't quite come out properly, but I expected as much. I am going to have to do some more digging and testing to figure out the best way to handle the data type conversion for long and float, as well as handling collections.
After some more testing, I was able to get collections to work in the second section. Just need to get the actual number conversions to work correctly. Though, there seems to be some inconsistencies with the spacing between the comments/items, though. I am not sure exactly why yet. I was just following the example when writing it to file, so it must be how I am creating the nodes and adding them to the TomlTable.
(For good measure I added a second item for each one without a comment just to make sure all was working well)
Here is what I have so far, would definitely appreciate any feedback (not completed yet, of course). I have got the current conversions all working properly now. As of this moment, I only added the things I was actually needing for my project. I just need to add the rest of the types, dictionaries, and some additional error checking, as well as supporting fields in addition to properties, etc. https://github.com/instance-id/TommyExtensions/blob/main/TommyExtensions/TommyExtensions.cs
Just did some multiline comment testing, seems to work out well. 👍
Update:
For the most part, I have both passing an instance of a data class containing properties able to write to file, as well as passing the class type and path to read from disk, which then returns a new instance of the class.
Write:
var path = "TestData.toml";
var testData = new TestData();
testData.StringProperty = "A String";
TommyExtensions.ToTomlFile(testData, path);
Read:
var path = "TestData.toml";
TestData testData = TommyExtensions.FromTomlFile<TestData>(path);
I believe last, but definitely not least, I have standard Dictionary<K,V> working both write and read. As of now, the final out put looks as follows.
This looks awesome!
Are you looking into merging this into Tommy repo directly? If so, I think it'd be better if you instead created a fork and made a pull request as this thread is looking less like an issue and more like feature implementation.
Moreover, with pull requests I'd be able to see and comment on the code (again, assuming you are looking into actually getting this merged).
Yeah, I would like to. I mostly just wanted to make sure I was doing things the proper and most efficient way, and things were working correctly before I did a PR. I still have a little cleanup to do, but as long as nothing crazy comes up, I should have that done tomorrow.
I mostly just wanted to make sure I was doing things the proper and most efficient way, and things were working correctly before I did a PR
In that case you can mark a PR as a draft. Either way, it would allow to review and comment the code and the PR in general. I will certainly do that once you actually post the PR, but it just may mean twice the work if there is something to change.
That sounds perfect, I will do that. I am just trying to figure out what might be the best way to go about actually adding it to the current project. While I was building it I had a solution with a project containing the actual extensions and one for the demo that added reference to the extensions. https://github.com/instance-id/TommyExtensions
What do you feel would be ideal, adding a new file or folder somewhere, or just taking my new code and adding it to your current Tommy/TommyExtensions.cs?
Looking at the project you linked, I think there are two options both of which are fine to me
TommyExtensions
file in this repo (which also gets packaged into the NuGet package)net35;netstandard2
(or at least add net35
to the current list of targets) so that the project is usable everywhere alongside the main libraryIf you go with the first option, I'll be more than happy to add a link to the final repo to the README of this repo so people can find it. Either way, I feel like it's better to keep the object (de)serializer as opt-in for users. Even right now I'm a bit unhappy with how I bundle TommyExtensions.cs
with the main Tommy.cs
in the NuGet package because that unnecessarily bloats the DLL for users who need simple low-level access to TOML.
Which of the two are you more comfortable with? As I mentioned, both work fine with me as long as in the end there will be a .cs
file or a NuGet package one can easily include into the project alongside Tommy.cs
to have the feature enabled.
You will have to forgive me, some of this is relatively new to me as I primarily do my development in C# for the Unity game engine and it is usually just small projects I make myself, simply pushing to my repo and call it a day, so I have been trying to use this as a bit of a learning experience.
That said, ever since your reply I have been trying to get net35 to work/add as a target but for whatever reason, it's just not happening in either Rider or VS. Windows says I have it, VS Installer says I have it, Rider even shows it added under dependencies, but I keep getting messages saying I don't have it when I try to build. With netstandard 2.0 it works fine, but something is up with 3.5. I will keep trying to get it figured out.
If for whatever reason I just can't get it to work I will make a PR instead with only the extensions (I created a new solution when things weren't working with 3.5, and renamed it to Tommy.Serializer and I renamed the actual class to TommySerializer, with the methods still being ToTomlFile and FromTomlFile)
Ok, finally got it worked out. Turns out, the issue ended up being not my IDE or configuration setup, but the .Net SDK itself. I kept trying to create new solutions, new projects, sometimes it might half work sometimes it would not even recognize the system assemblies, etc. I installed a different .Net SDK and then it worked almost straight away. I just had to make some slight adjustments to how I was getting attributes to work with .net 3.5, but as of now it is targeting and building for both 3.5 and netstandard2.0.
Hey there, I was just wondering if it were possible to read/write a file directly to/from a class, or am I going to have to manually assign each field? I didn't specifically see anything about it when I looked, but just wanted to make sure I didn't miss it somewhere if the functionality exists.
Thanks, -MH