On 2011-08-23 19:42, jdrewsen wrote:
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.:
Yes, that's how it works, but there are several ways to customize the
serialization process, see below. If you are interested, please look at
the unit tests: https://github.com/jacob-carlborg/orange/tree/master/tests
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
Orange have several ways to solve this.
1. Mark a field as non-serialized
class Foo {
int a;
mixin NonSeriailzed!(a);
}
2. Mark a whole class as non-serialized
class Foo {
mixin NonSeriailzed;
}
This will be handy for socket, thread, file and so on.
3. Custom serialization
class Foo {
int a;
void toData (Serializer serializer, Serializer.Data key) {
// serialize the class how ever you want
}
void fromData (Serializer serializer, Serializer.Data key) {
// deserialize the class how ever you want
}
}
4. Custom non-intrusive serialization
class Foo {
int a;
}
void serializeFoo (Foo foo, Serializer serializer, Serializer.Data key) {
// serialize the class how ever you want
}
void deserializeFoo (Foo foo, Serializer serializer, Serializer.Data key) {
// deserialize the class how ever you want
}
serializer.registerSerializer(Foo.classinfo.name, &serializeFoo);
serializer.registerDeserializer(Foo.classinfo.name, &deserializeFoo);
5. Events
class Foo {
int a;
void onSerializing () {
// invoked before serializing of Foo
}
void onSerialized () {
// invoked after serializing of Foo
}
void onDeserializing () {
// invoked before deserializing of Foo
}
void onDeserialized () {
// invoked after deserializing of Foo
}
mixin OnSerializing!(onSerializing);
mixin OnSerialized!(onSerialized);
mixin OnDeserializing!(onDeserializing);
mixin OnDeserialized!(onDeserialized);
}
--
/Jacob Carlborg
