The feedback from the recent post on reddit has given me some valuable feedback!
This feedback made me expand my already big todo list quite a bit more, so the next version will probably take a few days (or weeks?) to be completed.
However the wait is well worth it, check out the features I have planned for the future:
- Full support for Unity (the game engine)! This feature is already pretty much done (click here)
Because of the way Unity works I’m not sure if releasing this addon as a spearate nuget package would be good, maybe I’ll just make it into a .zip link or something.
That’s the most commonly used approach for unity-specific addons like this. MessagePack-CSharp does it as well. If you think there’s a good approach I haven’t considered yet, let me know 🙂 (If you’re reading this in the future then maybe the link above is invalid because I moved the addon to a better location within the repo)
Better dependency injection: This one is also already done. It’s about the DI system Ceras provides for your custom formatters (check out the previous post about custom formatters if you haven’t, the DI system is explained there). Previously it was not possible to request a specific formatter type, but now it is. This is especially useful to save performance since you don’t have the small overhead of interface-calls; and it also makes the whole experience a lot smoother to use.
Formatter-Constructed-Types. There will be a way that lets you specify that some type is supposed to be created by the formatter. Everything that can’t be created using
new(), like immutable collections, can thus be supported now in a much easier way.
ValueTupleformatters. Right now Ceras uses its dynamic formatter generator to support these, but it’s not optimal. Dedicated support for them will also make things faster.
Size limits for strings, collections, and arrays. Imagine a
[MaxLength(200)]attribute on an string or array, that Ceras uses when deserializing data. Very useful to prevent malicious input in case you’re using Ceras as a network protocol.
Create/Discard with static methods or concrete instances! If you have a
DiscardObjectmethod set in your config you know that you always need to check the type. That’s bad. But there’s another way. Lets stay with
ObjectFactoryas an example. What if we could just provide a static (or instance!) class instead, and have Ceras call specific methods on it? For example your class could have a method like
Person CreatePerson()and Ceras would call it with zero overhead to request a Person instance from you. That would simplify the way you interact with Ceras, as well as give quite some performance improvements (since method calls are compiled right into the dynamic code that Ceras generates)
Capacity constructors: As you probably know
Dictionary<,>, … have constructors that allow you to pass a capacity, so those classes don’t have to resize their inner arrays while entries are being added. That will definitely give you yet another a large performance benefit.
(maybe?) Merge-blitting: lets say you have a class that contains 3 “primitive” (int, float, …) fields (like a
Vector3!). At the moment Ceras will write every element individually, and every write calls
EnsureCapacity, that’s bad. What if we could instead merge all the capacity checks into one big check and then “blindly” write the values? I’d save us a lot of redundant checks, which can in some situations greatly improve performance! Not sure if that one will make it into the next version, but if not it will definitely be in the one after.
Better string encoding: Right now Ceras’ writes strings as fast as every other serializer using
Encoding.Utf8. But we can do a lot better actually… more details on that once its done 🙂
And the biggest one last, Presets: right now you can either construct Ceras with a
SerializerConfig, or you can skip it (in which case the default settings are used). One issue with that is the fact that many beginners will not use
KnownTypeswhen they should, which can lead to some huge problems. But instead of forcing everyone to use KnownTypes (which makes no sense anyway), I thought of a better solution. When creating an instance Ceras requires a “profile” so it knows how you intend to use it. Right now I can only really imagine 3 profiles (
Custom) and depending on what you chose some settings are pre-defined differently (you can still change them of course!). That would make it so beginners are much less likely to ignore important settings for their scenario. (specifically, requiring them to use
KnownTypeswhen they’re using Ceras for sending objects over a network).
Right now Ceras is on version
Especially the performance improvements require some breaking changes, to signal that the version number will be
In the future breaking changes will be much more rare (if there will be any breaking changes at all anymore!). In fact, I think this might be one of the last ones (maybe 1 more after this one, if even that).
As always, be sure to let me know if you have any feedback! 🙂
Ceras Repo: https://github.com/rikimaru0345/Ceras