mbeckerle commented on a change in pull request #473:
URL: https://github.com/apache/incubator-daffodil/pull/473#discussion_r562228274
##########
File path:
daffodil-runtime1-unparser/src/main/scala/org/apache/daffodil/processors/unparsers/ExpressionEvaluatingUnparsers.scala
##########
@@ -77,30 +76,52 @@ final class SetVariableUnparser(
}
+final class NewVariableInstanceSuspendableExpression(
+ override val expr: CompiledExpression[AnyRef],
+ override val rd: VariableRuntimeData)
+ extends SuspendableExpression {
+
+ override protected def processExpressionResult(ustate: UState, v:
DataValuePrimitive): Unit = {
+ ustate.variableMap.newVariableInstance(rd, v)
+ }
+
+ override protected def maybeKnownLengthInBits(ustate: UState) = MaybeULong(0)
+}
+
Review comment:
This may ultimately just be a flaw in the DFDL language notion of
variables. They're supposed to be single-assignment variables, but this mixture
of defaultValue and setVariable where a read locks down the default value was
always a sketchy design point because things become very order dependent, and
since the unparser does things out of order due to suspensions and forward
reference, the tenuous interactions of these things become problematic.
A way to fix this is to say that for any variable that has unparse direction
(so both or unparseOnly) you have to pick whether you use *only* defaultValue
expressions to bind values to it, or whether you will use setVariable
statements, in which case the variable cannot have any default value in the
base defineVariable nor in any newVariableInstance statements. This I think
fixes all these issues. A variable is either defaultable, and not settable, or
it is settable and not defaultable. I think these restrictions are very
livable.
----------------------------------------------------------------
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]
