mbeckerle commented on a change in pull request #539:
URL: https://github.com/apache/daffodil/pull/539#discussion_r621407281
##########
File path:
daffodil-runtime1/src/main/scala/org/apache/daffodil/processors/DataLoc.scala
##########
@@ -33,9 +33,20 @@ import org.apache.daffodil.util.MaybeULong
import org.apache.daffodil.api.DataLocation
import org.apache.daffodil.processors.parsers.PState
-class DataLoc(val bitPos1b: Long, bitLimit1b: MaybeULong, val isAtEnd:
Boolean, eitherStream: Either[DataOutputStream, DataInputStream],
+class DataLoc(
+ val bitPos1b: Long,
+ bitLimit1b: MaybeULong,
+ eitherStream: Either[DataOutputStream, DataInputStream],
val maybeERD: Maybe[ElementRuntimeData]) extends DataLocation {
+ @deprecated("Use bitPos1b to compare with expected position (possibly
bitLimit1b).", "3.1.0")
+ override def isAtEnd =
+ eitherStream match {
+ case Right(isdis: InputSourceDataInputStream) => isdis.isAtEnd
Review comment:
Ultimately, a ParseResult should be an immutable object, excepting the
InputSourceDataInputStream within it, which is obviously mutable.
We can't answer isAtEnd without potentially mutating the ISDIS, so that
can't be part of an immutable ParseResult.
So really the problem is loc.isAtEnd shouldn't be on the loc object, because
we want the loc object to be immutable. That's a big reason to deprecate
isAtEnd. The bit pos and bit limit information on a DataLoc is immutable.
In the latest commit, hasData() is on the DataInputStream, and there is no
equivalent on DataLocation/DataLoc.
I think adding a tunable here is overkill. Deprecating isAtEnd on loc, is
easy to replace it with getting the data input stream and calling hasData().
--
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]
