Replies: 3 comments
|
It would be great if we can enforce it using static analysis (lint). I have no idea if there are any lints having such rule though… |
|
I wish it was that simple, but I think we might want to also enforce something like If we have a strong enough contract, then I think it'd help for outside/new contributors to follow more easily. 😗 |
|
On the other hand, this effort may be unnecessary or will affect only a very limited duration since .NET seems to decide to step down the legacy serialization API, including |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
When an object is serialized in .NET, it is often necessary for that field to be serializable. (e.g., best practices about custom exceptions), And when the object being serialized is out of our control, this can be a big problem.
So rather, I suggest that we proactively implement
ISerialzablefor the types we expect to be treated as data in Libplanet, and prevent this implicit field serialization. This can be easily applied to types for which we already have (de)serialzation methods, such asBlock<T>orTransaction<T>.The following is an example when applied to
Transaction<T>.All reactions