Uploaded image for project: 'Daffodil'
  1. Daffodil
  2. DFDL-1113

asLong has a case for java.math.BigInteger. Everything else is scala's BigInt.


    • Icon: Improvement Improvement
    • Resolution: Duplicate
    • Icon: Normal Normal
    • 2.0.0
    • None
    • None
    • None

      I do not know why for this one test (name escapes me now, but we can find it by just commenting out the case for java.math.BigInteger in asLong)

      I ran tests, got 1 test failure, was due to a BigInteger being passed in.

      The bigger task is rationalizing exactly what goes in the infoset for every simple type, and then having expressions expect only those things, only the right ones. I.e., dates should be carried around as Calendar (or DFDLCalendar?), not as strings. HexBinaries always as Array[Byte], etc. There is a fair amount of slop right now where things tolerate many differnet kinds of inputs because things weren't predictable enough or consistent enough about what they put in the infoset. But the compiler structure is there to establish the type an expression will receive from its sub-expressions, and if it can expect exactly that, well all these asInt, asLong, etc. match-cases could go away.

              twise Taylor Wise
              mbeckerle.dfdl Mike Beckerle
              0 Vote for this issue
              1 Start watching this issue