zorba-coders team mailing list archive

[Chris Hillery <chillery+launchpad@xxxxxxxxx>]

David: 

1. I agree, the duplication of code to output attributes is not pretty. I don't think it would be too difficult to add support for directly serializing attributes to the serializer itself. And it wouldn't have to be changed in every emitter, only whichever emitter is used for basic XML serialization.

2. I think adding the serializer to the either the state or the iterator class is the right answer. I'm not quite clear enough on how the whole state/STACK_PUSH stuff works in the runtime to say whether the state or the iterator is the better place for it.

I don't immediately see any problem with adding the #include of serializer to the corresponding header file. If you're desperate to avoid this, however, you could have a forward reference to Serializer and put a Serializer* on the appropriate class. Yes, that means the Serializer would need to be heap-allocated and you'd have to worry about de-allocating it in the destructor.

I wonder if you could have a forward reference to Serializer and then have a data member that was an auto_ptr<Serializer> or unique_ptr<Serializer>?
-- 
https://code.launchpad.net/~davidagraf/zorba/trace_without_debug_info/+merge/110377
Your team Zorba Coders is subscribed to branch lp:zorba.