On 03/06/12 20:37, H. S. Teoh wrote:
> On Tue, Mar 06, 2012 at 01:51:51AM +0100, Artur Skawina wrote:
> [...]
>> class A {
>> string prop1;
>> int prop2;
>>
>> void serialize(this THIS)() {
>> __serialize(cast(THIS*)&this);
>> }
>> }
>>
>> void __serialize(T)(T* obj) {
>> writef("%s {\n", typeid(*obj));
>> foreach (name; __traits(allMembers, T)) {
>> static if (__traits(compiles,&__traits(getMember,obj,name))) {
>> alias typeof(__traits(getMember,obj,name)) MT;
>> static if (is(MT==function))
>> continue;
>> else {
>> auto m = __traits(getMember,obj,name);
>> if (is(MT:const(char[])))
>> writef(" %s %s = \"%s\";\n", typeid(MT), name, m);
>> else
>> writef(" %s %s = %s;\n", typeid(MT), name, m);
>> }
>> }
>> }
>> writef("}\n");
>> }
>>
>> And it will do the right thing for derived classes too.
> [...]
>
> Hmm, it only does the right thing for derived class if invoked with the
> derived class pointer. It doesn't work (and in retrospect can't possibly
> work, since "this THIS" is a compile-time parameter) if you only have
> the base class pointer.
Of course. But is it really necessary to fully serialize derived classes
*w/o* knowing what they are? In that case deserialization will probably be
"interesting" too...
> What I needed was for serialize() to be polymorphic at runtime, so it
> does have to be overloaded in every derived class. Hmph... looks like I
> can't avoid using mixins. :-(
If you can "register" the classes to be serialized then typeid() can help
the __serialize() implementation...
On 03/06/12 11:43, Timon Gehr wrote:
> On 03/06/2012 01:51 AM, Artur Skawina wrote:
>> ...
>> Real programmers don't use mixins, :^)
>
> You got it reverse.
Mixin programmers don't use reals? :)
Seriously though, many (most?) uses of mixins are caused by language
deficiencies; sometimes the mixins are necessary, but often a cleaner
solution would have been possible, with a little more help from the compiler.
artur
