Chances of D getting proper runtime reflection?

[Marco Leise]

Am 24.08.2011, 08:58 Uhr, schrieb Jacob Carlborg <doob at me.com>:

> On 2011-08-24 08:41, Marco Leise wrote:
>> Am 23.08.2011, 19:42 Uhr, schrieb jdrewsen <jdrewsen at 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?