Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Further demos to distinguish valid and invalid class structures. This is much more strongly-typed now, yay! This is what I have been hoping for. When I first thought of the NBT structure class builder idea, I was also considering having methods on the class too, but I don't think that makes sense when you think about it. I think I was trying to do too many things on the same level of the object. So I think this actually helps make the abstraction a bit simpler than I thought it should go, which is better. Having a mix of values/properties, and methods to work with that data, it doesn't really make sense for NBT representation. I want the class more to generate default values if you wanted to create a new NBT object representation from scratch, if I were to add that into the MC API. So, something like `new BedrockLevelDat()` would give you the same NBT object structure as a plain `level.dat` file, but with the defaults of a new world, unedited. Come to think of it, I think this is kind of what I'm looking for, but I think using interfaces for the main NBT objects probably makes more sense, and to just use functions to make the objects, instead of classes. I could maybe see using classes for the `NBTData` representation of the file as a whole, but maybe that would suffer from the same issues, and it wouldn't make as much sense to build it like that. It could also make sense to use functions for that too, one for the internal `BedrockLevelDatLike` object for `NBTData.data`, and `BedrockLevelDat` for the `NBTData` wrapper, instead? That seems kind of like a neat idea too. It's a bit easier to do things at the type level too, rather than using objects, I can do union discriminant types for each of the platforms, and it can use NBTify's data primitives better too, since it won't use inheritance to describe the shapes of things. #28
- Loading branch information