bsloane1650 commented on a change in pull request #207: Added support for 
enumerations and TypeValueCalc
URL: https://github.com/apache/incubator-daffodil/pull/207#discussion_r275565958
 
 

 ##########
 File path: daffodil-lib/src/main/scala/org/apache/daffodil/util/Cursor.scala
 ##########
 @@ -160,18 +196,24 @@ trait CursorImplMixin[AccessorType <: 
Accessor[AccessorType]] { self: Cursor[Acc
     val res = priorOpKind match {
       case Advance => {
         priorOpKind = Inspect
-        doAdvance(true)
+        doAdvance(true, true)
       }
-      case Inspect => true // inspect again does nothing.
+      case InspectPure => {
+        priorOpKind = Inspect
+        doAdvance(true, advanceInput=false)
+      }
+      case Inspect      => true // inspect again does nothing.
       case Unsuccessful => return false
     }
     // successful
     Assert.invariant(isFilled == true || !res)
     res
   }
 
-  private def doAdvance(isFilledValue: Boolean) = {
-    val res = fill()
+  //inpsectPure implemented in InfosetInputter.scala
+
+  private def doAdvance(isFilledValue: Boolean, advanceInput: Boolean) = {
 
 Review comment:
   The issue is that in the InfosetCursor implementation, constructing the 
object has side effects. So, in order to use the 1 object lookahead, the side 
effects associated with creating an object occur when you use the lookahaed, 
instead of when you actually consume the object. This means that there is no 
way to inspect any aspect of the next object without triggering the side 
effects associated with creating it.
   
   InspectPure provides a limited 1 object look ahead that can be used without 
triggering the side effects associated with constructing the full object like 
inspect would.
   
   In more practical terms, inspectPure provides only the ElementRuntimeData, 
while inspect provides a DINode.
   
   This is actually orthogonal to the difference between more traditional 
iterators. We would have the same problem with a next()/hasNext()/peek() style 
API, as our implementation of peek() would have the same side effects as 
inspect() does now.
   
   The API of Cursor itself is actuall pretty sane. The problem comes when we 
make InfosetCursor use Accessor[DINode], as that requires making 
inspect()/next() have unexpected side-effects.

----------------------------------------------------------------
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

Reply via email to