adding properties/methods to AA's?

Bill Baxter dnewsgroup at
Mon Jul 23 18:35:33 PDT 2007

Jarrett Billingsley wrote:
> "Bill Baxter" <dnewsgroup at> wrote in message 
> news:f81g6k$o47$1 at
>>   static import varchar; // has serialize for Variant[char[]]
>>   static import intint; // has serialize for int[int[]]
>>   intint.serialize(map);
>>   varchar.serialize(map2);
>> Or just give the functions different names to begin with.
> Templates, man!  Templates and IFTI! 

... and a serialize() method in any user types that you want to use as 
keys/values in the map.

Not sure what you were thinking of exactly, but a reasonable start to a 
templated map serializer function would be:

ubyte[] serialize(VType,KType)(VType[KType] map)
    ubyte[] ret = serialize(map.length)
    foreach(v,k; map) {
        ret ~= serialize(v);
        ret ~= serialize(k);
    return ret;

You still need to have serialize() implemented somewhere for uint, VType 
and KType.  So what you end up having to do is what writefln does. 
You can provide implementations of serialize() for all the built-ins in 
the serialization module, but non-built-ins have to implement a special 
member function (a la "toString" for writefln).

That makes it difficult to extend the serialization system to include 
3rd party objects not created with your serialization framework in mind.

These are the kind of cross-cutting functionalities that become 
difficult to implement in a completely generic and extensible way 
without argument dependent (Koenig) lookup.

Just thinking here -- I wonder if there might be some way to use 
CTFE/mixin type stuff to get around that.  For instance instead of 
trying to call the 'serialize' method for a class, the template would 
try to call the function named "serialize_" ~ typeof(argument).stringof 
using a mixin.  Then in your myclass.d module you define class MyClass, 
and also a serialize_MyClass(MyClass mc) {...}.


More information about the Digitalmars-d-learn mailing list