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 : firstname.lastname@example.org
Unsubscribe : https://launchpad.net/~zorba-coders
More help : https://help.launchpad.net/ListHelp