stevedlawrence commented on a change in pull request #207: Added support for
enumerations and TypeValueCalc
URL: https://github.com/apache/incubator-daffodil/pull/207#discussion_r279766883
##########
File path:
daffodil-runtime1-unparser/src/main/scala/org/apache/daffodil/processors/unparsers/ElementUnparser.scala
##########
@@ -167,7 +174,9 @@ sealed abstract class ElementUnparserBase(
}
protected def runContentUnparser(state: UState) {
- if (eUnparser.isDefined)
+ if (eReptypeUnparser.isDefined) {
+ eReptypeUnparser.get.unparse1(state)
+ } else if (eUnparser.isDefined)
eUnparser.get.unparse1(state)
Review comment:
It looks like we always use either the eRepTypeUnparser or the eUnparser,
and never both. And the combinator doesn't really care which it's using. So,
does it make sense to change this so the primitive either passes in the rep
type unprarser or the normal unparser based on if repType is defined? From what
I can tell, the eUnparser is never going to be used if reptype is defined. Same
thing goes with the parser side of things.
This avoids added a new parameter to all these element combinators, keeping
them mostly the same, I think?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
