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>?
Your team Zorba Coders is subscribed to branch lp:zorba.

Mailing list: https://launchpad.net/~zorba-coders
Post to     : zorba-coders@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zorba-coders
More help   : https://help.launchpad.net/ListHelp

Reply via email to