Am 24.08.2011, 08:58 Uhr, schrieb Jacob Carlborg <d...@me.com>:
On 2011-08-24 08:41, Marco Leise wrote:
Am 23.08.2011, 19:42 Uhr, schrieb jdrewsen <jdrew...@nospam.com>:
Den 23-08-2011 17:03, Jacob Carlborg skrev:
On 2011-08-23 16:38, Andrei Alexandrescu wrote:
On 8/23/11 12:55 AM, Jacob Carlborg wrote:
On 2011-08-23 08:52, Andrei Alexandrescu wrote:
On 8/22/11 11:30 PM, Jacob Carlborg wrote:
Ok, then I just change "register" to a static method.
A static method of whom?
Andrei
Well, "register" currently an instance method of Serializer so I
would
change it to be a static method of Serializer.
I think the ability of a class to be serialized would be independent
of
the notion of a serializer. To me, "this class is serializable"
really
means "this class has metadata associated with it that allows
interested
parties to serialize it". But perhaps this is splitting hairs.
Andrei
You don't want to have it in the class and don't want it in the
serializer. I mean, it needs to be stored somewhere and I thought
that a
static method in Serializer would better than a completely global
function.
Are you thinking about having another serialization library that can
use
this information as well? I'm not sure if that's good idea, different
serialization implementations might need to do very different things
with the information.
It could be used for network transmissions. Correct me if I'm wrong
but Orange serializes the entire object. When sending things over the
network or when saving something to disk for that matter you most
likely are only interested in serializing some of the fields of an
object. I really think it would be nice to declaratively mark fields
as serializable for certain purposes e.g.:
class Foo {
int a; // Send over network and saved to file
int b; // Saved to file
ubyte[] cache; // not to be serialized
}
mixin(serialize!(Network, Foo, a);
mixin(serialize!(File, Foo, a);
mixin(serialize!(File, Foo, b);
// but still support not specifying each field
class Bar { int a; }
mixin(serialize!(File, Bar));
Another way would be to just declare a class as serializable and then
for each serialization type (ie. Network, File) declare that they
should skip a field. Actually I think I better like this approach
since it would allow decoupling of serialization type and the
declaration of serializability.
/Jonas
These are good points Jonas. It's a good idea to read up on
http://en.wikipedia.org/wiki/Serialization
I used Java for a while and I they have their reasons to require a
'tag'/'annotation'/'interface' on serializable classes.
Java's choice to not make serializable a default is explained in short
like this:
- structures like threads or files cannot maintain their semantics when
serialized
- classes and libraries change over time, this adds extra work for the
maintanance of serializable classes
- serialization means externalization of private attributes, even
passwords
.NET adds the option to mark newly added fields as OptionalField, so a
previously serialized instance can be loaded without error.
NonSerialized marks a field as not serializable which is what Jonas
mentioned. Like Java they work with interfaces to declare methods called
after deserialization, so the 'cache' in the above example can be
reinitialized correctly.
Orange supports NonSerialized fields and classes, (de)serialization
events and several other ways to customize the serialization process.
It's inspired by how serialization in .NET works.
For more information see the Orange unit tests:
https://github.com/jacob-carlborg/orange/tree/master/tests
Then I'll clearly use Orange when I have a need for serialization. Nice
work!
I've taken a closer look at
http://dsource.org/projects/orange/wiki/Features and I see that versioning
is still missing. What are your plans there? What happens at the moment
when I deserialize and object with missing/added fields?
