|
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#...
|
|
|
|
|
|
I was about to replay (once again, like 2 thread above above protocol buffer): Ignorance.
But then, following your link (for Avro serializer at least) and going down the memory lane on protocol buffer with a CP Article, the answer is obvious: I want something as simple as NewtonSoft JsonConverter. It should just work!
And also it should work with object or subclass.
And while you can use some attribute with it, it should work fine without any!
In a word I want to serialize that (without any more hidden work!):
class Data {
public object Something;
public List<object> MoreThings { get; } = new List<object>();
}
|
|
|
|
|
Upgraded from 10.1 to 15.2, got a bunch of deprecated warnings, but the app came up! Which is saying something, because I'm not using just the vanilla DX controls, they're all sub-classed with lots of custom additions.
Marc
|
|
|
|
|
Going from WinForm controls version 12 to 13 (I think it was) broke some one of our subclasses pretty bad (years ago) 
Other than that I have only good experiences with DevExpress 
I'm pretty sure that if you added a support ticket "trying to update v1 to the latest greatest and it's not working" they'd give you a helpful answer within a day 
|
|
|
|
|
Wait... Wait...
I'm getting a message from... Beyond...
I...
Yes, I see...
... The spirits tell me that DevExpress was not made by adobe or microsoft.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: ... The spirits tell me that DevExpress was not made by adobe or microsoft.
Is that a good thing or a bad thing?
I can still run my Win95 program on Windows 10... so it's probably a bad thing! 
|
|
|
|
|
Super Lloyd wrote: I can still run my Win95 program on Windows 10... so it's probably a bad thing!
You should be able to run every single win'95 program on winio, because that is the just one job that an operating system has to do.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: I'm getting a message from... Beyond...
Ack. You sound like my ex.
Marc
|
|
|
|
|
|
Let's nuke them before this gets out of hand!
Get me coffee and no one gets hurt!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
