compiler support added for precise GC

[deadalnix]

Le 17/04/2012 14:31, Alex Rønne Petersen a écrit :
> On 17-04-2012 10:13, Walter Bright wrote:
>> On 4/17/2012 1:10 AM, Walter Bright wrote:
>>> On 4/16/2012 11:50 PM, Jacob Carlborg wrote:
>>>> On 2012-04-17 08:33, Walter Bright wrote:
>>>>> On 4/16/2012 11:26 PM, Jacob Carlborg wrote:
>>>>>> Then it won't be possible to serialize third party types if they
>>>>>> don't
>>>>>> implements ISerializable. In this case, this solution is no better
>>>>>> then manually
>>>>>> registering types. Actually it's worse, since I can manually register
>>>>>> third
>>>>>> party types.
>>>>>
>>>>> I'm not so sure in D that you can serialize arbitrary types without
>>>>> them
>>>>> designed to be serializable. For example, what will you do with
>>>>> unions?
>>>>> Pointers to global data?
>>>>
>>>> Not all types are serializable of course.
>>>
>>> How would you know if they are or aren't, when dynamically loading
>>> stuff?
>>
>> Essentially, I'm concerned with a vast amount of data being generated
>> for every type and inserted into the executables (which are already
>> large). Even worse, I'm concerned that such a feature will not "just
>> work" when one wants to serialize a class that wasn't designed to be
>> serialized, and it'll come off as a crappy half-assed buggy misfeature.
>
> Would turning on global reflection data generation with a compiler
> switch be reasonable? Then when libraries query for reflection
> information, they just have to check whether it's actually there (and if
> not, most likely error).
>
> Anyway, I don't think reflection has the potential to be a misfeature;
> that's stretching it. Redundancy can certainly be incurred, but with a
> switch to enable reflection, it would only happen when the user actually
> wants it to.
>
> As for the just works factor - if the serialization library is designed
> well enough (which I'm confident Jacob's library either is can be made
> to be), it isn't really a problem. Serializing a graph of objects is
> pretty standard (see e.g. .NET binary serialization).
>
> Even better, the library could just error out (instead of producing
> garbage) when it discovers that it can't serialize a type in any
> sensible fashion.
>

I don't see any need for runtime reflection here.

If a type is serialized, at some point it have to be given to the lib, 
that can generate runtime information from compile time reflection 
capability. If the type is never serialized/deserialized, then runtime 
reflection is useless.