April 17, 2012
On Apr 16, 2012, at 7:20 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 4/16/12 1:02 PM, Sean Kelly wrote:
>> As for pointer maps, I think it's reasonable to establish a format that these will be made available to the GC, and for them to come from elsewhere in the runtime.  I realize that different GC implementations may prefer different formats, but hopefully we can settle on one that's pretty generally usable and efficient.  I'd really rather avoid expecting GC writers to know how to meta-process D types to statically generate this themselves.  Moving this into the GC would also eliminate the possibility of having the GC chosen at link-time, which is something that's currently still an option.
> 
> I know you didn't mean it that way, but this gets close enough to a dogma to warrant a protest. "We don't need no steenkin' templates in <sacred area X>" is, I think, an attitude we need to just rid ourselves of. There's the same harm in using templates too much or too little.
> 
> The scheme Walter proposed has a lot of flexibility - it plants one pointer to function per type. This is very flexible because that pointer could point to the same function and use a bitmap-based scheme, or (as Walter proposed) point to different instances of a template that does scanning in a type-specific manner.

Fair enough. How about core.memory?  That's the visible GC interface, and would be where template-based GC methods are defined. It still limits all GC implementations to a single pointer map representation though, without some theatrics.
April 17, 2012
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. For those types you would have to register a function or similar. But most other types are possible to automatically serialize. I don't see a point in making them less serializable by requiring to implement an interface. I also think mostly one would want to serialize objects or an hierarchy of objects.

-- 
/Jacob Carlborg
April 17, 2012
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?

> For those types you would have to
> register a function or similar. But most other types are possible to
> automatically serialize. I don't see a point in making them less serializable by
> requiring to implement an interface. I also think mostly one would want to
> serialize objects or an hierarchy of objects.


April 17, 2012
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.
April 17, 2012
Le 17/04/2012 05:22, Walter Bright a écrit :
> On 4/16/2012 7:20 PM, Andrei Alexandrescu wrote:
>> The scheme Walter proposed has a lot of flexibility - it plants one
>> pointer to
>> function per type. This is very flexible because that pointer could
>> point to the
>> same function and use a bitmap-based scheme, or (as Walter proposed)
>> point to
>> different instances of a template that does scanning in a
>> type-specific manner.
>
>
> It could also be a pointer to data. It's entirely up to the template
> what it's a pointer to.

Data can eventually be stored IN the pointer if needed. Does the system allow that ? If it doesn't, is it possible to enable it ?
April 17, 2012
Le 17/04/2012 08:26, Jacob Carlborg a écrit :
> On 2012-04-16 22:42, Timon Gehr wrote:
>
>> This could be fixed by introducing a simple language feature that allows
>> a supertype to specify mixin templates that are 'inherited' by all
>> subtypes.
>>
>> Eg:
>>
>> interface ISerializable {
>> ubyte[] serialize();
>>
>> super mixin Serialize;
>> }
>
> 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.
>

Any type that mixin Serialize would be serializable, which is pretty nice.

Another way would be to inherit attribute. Then a runtime reflection script can retrieve all declaration with a given attribute.
April 17, 2012
On 2012-04-17 10:13, Walter Bright wrote:
> On 4/17/2012 1:10 AM, Walter Bright wrote:
>> How would you know if they are or aren't, when dynamically loading stuff?

I'm not entirely sure what you mean by "dynamically loading stuff". The only types you can create dynamically are objects:

auto b = Object.factory("Bar");

D has a limited set of types and a couple of user definable types, like classes, structs and so on. So in my serialization library it's basically hard coded what's serializable or not. All primitive types, int, char, string and so on are serializable. All classes and structs are serializable as well.

It essentially works like this. You always need to start with a static type, like this:

struct Foo { ... }

auto a = deserialize!(Foo)(data);

From that I can figure out most of the things via compile time reflection. What's not possible is when the runtime type is different from the static type:

class Base { ... }
class Sub : Base { ... }

Base b = new Sub;

In the above code, when inspecting "b" using compile time reflection all information about "Sub" is gone. It's just a regular "Base".

> Essentially, I'm concerned with a vast amount of data being generated
> for every type and inserted into the executables (which are already
> large).

Most of the data is already available in the symbol table anyway. Instance methods, static methods and static variables. What's missing is basically instance variables and an easy way to access them.

> 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.

Sure that can always happen. But as long as the data is there it's up to the serialization library how to use it. When serializing third party types not explicitly made for serializing it would be up to the user to know what he/she's doing. I mean, this is a system programming language just as you can cast away shared an similar.

Feel free to use my serialization library and see what it can handle:

https://github.com/jacob-carlborg/orange

-- 
/Jacob Carlborg
April 17, 2012
On 2012-04-17 10:50, deadalnix 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.
>>
>
> Any type that mixin Serialize would be serializable, which is pretty nice.

It's even nicer if that's not needed. Again, what I said above.

> Another way would be to inherit attribute. Then a runtime reflection
> script can retrieve all declaration with a given attribute.


-- 
/Jacob Carlborg
April 17, 2012
On 4/17/2012 1:47 AM, deadalnix wrote:
> Le 17/04/2012 05:22, Walter Bright a écrit :
>> On 4/16/2012 7:20 PM, Andrei Alexandrescu wrote:
>>> The scheme Walter proposed has a lot of flexibility - it plants one
>>> pointer to
>>> function per type. This is very flexible because that pointer could
>>> point to the
>>> same function and use a bitmap-based scheme, or (as Walter proposed)
>>> point to
>>> different instances of a template that does scanning in a
>>> type-specific manner.
>>
>>
>> It could also be a pointer to data. It's entirely up to the template
>> what it's a pointer to.
>
> Data can eventually be stored IN the pointer if needed. Does the system allow
> that ? If it doesn't, is it possible to enable it ?

I don't know what you mean.
April 17, 2012
On Monday, 16 April 2012 at 20:42:19 UTC, Timon Gehr wrote:

> This could be fixed by introducing a simple language feature that allows a supertype to specify mixin templates that are 'inherited' by all subtypes.
>

Similar proposals have been made in the past (http://www.digitalmars.com/d/archives/digitalmars/D/Defining_some_stuff_for_each_class_in_turn_97203.html) but failed to get through. BTW, 'alias this' complicates things since most features that are valid for subclassing are now expected to be valid for 'alias this' subtyping as well.