|
The Serializer write to an interface I created call IPrimitiveWriter
I provide 2 implementation of IPrimitiveWriter
public class PrimitiveBinaryWriter : IPrimitiveWriter
{
public PrimitiveBinaryWriter(Stream stream)
}
public class PrimitiveTextWriter : IPrimitiveWriter
{
public PrimitiveTextWriter(TextWriter writer)
}
So... binary output is covered. And it's also forward only (unlike first version, haha), so the stream can be a GZipStream.
The text output is there mostly for fun. It also provide a tiny help for debugging and help me check there is no repetition (all reference, including string should be there only once)
|
|
|
|
|
Great! Looking forward to trying it after your CP Article.....
|
|
|
|
|
|
Super Lloyd wrote: since I shared plenty of reflection extension method....
An article in itself. I've been having fun with reflection and LINQ, but I'd really like to see some cool reflection extension methods, as well as that serializer that you describe.
Marc
|
|
|
|
|
Not something which struck my mind initially...
But now that you mention I have handy methods to try to call a constructor or a method... using a list of parameters... and they match using default value as well!
Which I haven't seen very often!
(using LINQ magic it's just one BIG statement! haha!)
Might do a tips / trick for those instead.. less work! 
Other than those astute methods (TryConstruct() TryInvoke() TryConvert()) the rest is various very simple method to plug the hole in the PCL version of Reflection.
|
|
|
|
|
In fact I also have another serialization utility.
I didn't think of it since it has nothing to do with the serializer.
But it let you write something this handy!
doNotCollect = PropertyPath.Watch(aValue, x => x.A.B.C.D, newD => { });
|
|
|
|
|
|
Versioning support:
Can it read a stream written by an older version, with well-defined and useful behavior for the properties not present in the stream?
Can it read a stream written by a newer version that contains properties it does not understand?
Another problem I've commonly ran into is class invariants: they must be guaranteed when the class is properly constructed, but during serialization, it is not.
Typically, they are enforced through getters/setters - but if a serializer initializes an object through those, it can encounter incorrect intermediate states.
If constraints are not checked during read, then you need a separate function validating the object, duplicating the code in the getters / setters.
I haven't encountered a enjoyable solution to that problem that did not end with "well, then you have to change how your class is implemented".
Or, to snowclone a wonderful quote: The amount of serializers available is a sure sign that none of them really works.
|
|
|
|
|
Hey,
The intent of this serializer is to replace JsonSerializer (NOT the .NET Serializer) (i.e it's a document serialize, won't work on WPF/WinForm class, unfortunately...) while being way more compact, support IList, IDictionary (normal and generic version), be strongly typed yet type error tolerant. I also dropped human readability format. Text output is just for (painful) debugging purpose.
It also DOES NOT support delegates.
It is, indeed, not perfect....
Also it doesn't support TypeConverter / ValueConverter / ISerializable, but I am thinking to add support for them...
So to address each point in detail:
- by default it only serialize public fields and property. This can be modified with attribute on the class and/or field/property.
- what about versioning? It doesn't care if the property is missing while deserializing it is ignored
- class invariant... Right now one can enumerate all reference object deserialized with the ObjectContext of the deserializer. I was thinking / maybe to go one step further and create an IDeserialized interface to automatically "awake / complete" objects after deserialization
- also difficult type to serialize can be helped with an "easy" to implement ISurrogate<> class, define this class to replace problematic type when serializing / deserializing
public interface ISurrogate<T> {
void Initialize(T value);
T Instance();
}
- thinking of WPF.. I just realized that some readonly property (such as Children UI component) while being readonly, can still be serialized as an IList, should be fixed by publication time! 
Forget that, it cause too much ambiguity about the serizalizer, since it can also (optionally) serialize private field.
modified 22-Jun-16 16:58pm.
|
|
|
|
|
Soudns good to me  `IDeserialized` would allow to cope with many common problems I've encountered. `ISurrogate` could nicely isolate some complexity from the class / serializer itself.
Your striked-out part reminds me of another thing: read only Collections (they are managed internally) where the elements are mutable and should be serialized.
This could be handled in IDeserialized if I could construct thecollection there and then request serialization for the collection members.
|
|
|
|
|
Great to know IDeserialized works out for you!
I needed such concept for my IoC+IServiceProvider to completely initialize object tree (it's called IRegistryDelegate for that). Came with that there first! 
After all the comments I decided to add yet more functionalities and now it's all broken....
Plus, exceptionally, I work this Saturday!  (this my home project, not the work one)
So it's gonna be delayed some more...
But the current (broken) version does support ISerializable (but not [SerializableAttribute] which assume private field reading), TypeConverter (but not ValueSerializer which are not PLC / .NET Core) and it also support restoring public readonly reference property, such as:
public List<T> Children { get; } = new List<T>();
public Configuration Configuration { get { return existingConfig; } }
I was misleaded, proved easy and helpful!
ETA should be end of next week now...
|
|
|
|
|
Super Lloyd wrote: So it's gonna be delayed some more...
No worries, I'll be on vacation for a week. 
(I expect it on my desk when I return, 9am point  )
|
|
|
|
|
9am sharp! alright!
|
|
|
|
|
|
I'm impressed!
The introduction on GitHub already looks good - haven't dug deeper yet, though.
|
|
|
|
|
Thanks!
Just committed some performance improvements!
CodeProject article is next... might take a while...
|
|
|
|
|
|
Haha, thanks!
|
|
|
|
|
After JSON was popularized, making own serializer is just one more try to blush.
|
|
|
|
|
Nah...
While I be happy to be popular with it, I won't deny it! 
Its primary aim is to provide a much needed help with super secret project (where JSON just won't do)...
|
|
|
|
|
One question pops out though: why not protobuf.net? Protocol buffers provide extremely space efficient binary files, with versioning support, and .NET port can use reflection to configure the serializer without attributes. It's also among fastest serializers out there.
|
|
|
|
|
Well... ignorance perhaps?
I am only proficient with the .NET Serializer, DataContractSerializer, XmlSerializer and JsonSerializer.
None of them satisfied me...
So a few question about protobuf:
1. can it save IList, IList<T>, IDIctionary, IDictionary<K, V> ?
2. can it provide a simple mechanism (like surrogate) to serialize opaque type like Bitmap?
3. can it cope with a class which have different property altogether after serialization?
3.a. how does it do (3)? My serializer do 3 by saving class meta data once so that it knows what to read... does it do the same or does it save like JSON: ('property name' 'property value'), one my main contention with JSON... my serializer save type metada once, then only ('property value' 'property value' 'property value'......)
|
|
|
|
|
I'm not sure why but I'm always interested in a new serializer!
+1 for article
You might be interested in Transit [^]from the Clojure community that allows for self-describing extensibility.
|
|
|
|
|
Haha thanks...
I had a quick look at Transit.. but it's not C#!
All my super secret take over the world project are in C#...
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
