Chances of D getting proper runtime reflection?

[Marco Leise]

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.