bsloane1650 commented on a change in pull request #264: WIP - DAFFODIL-2169
URL: https://github.com/apache/incubator-daffodil/pull/264#discussion_r307049601
##########
File path: daffodil-lib/src/main/scala/org/apache/daffodil/util/DataValue.scala
##########
@@ -0,0 +1,91 @@
+package org.apache.daffodil.infoset
+
+import java.lang.{ Boolean => JBoolean, Number => JNumber, Long => JLong,
Double => JDouble, String => JString, Float => JFloat, Byte => JByte, Integer
=> JInt, Short => JShort }
+import java.math.{ BigDecimal => JBigDecimal, BigInteger => JBigInt }
+import org.apache.daffodil.calendar.DFDLCalendar
+
+/*
+ * DINode is not visible to Daffodil-lib, so we cannot actually reference this
here.
+ * We are trusting the rest of the codebase to only apply DataValueDINode to
the DINode
+ * class.
+ * The DINode class itself defines an implicit DataValueDINode -> DINode
conversion
+ */
+trait DataValueDINodeTrait extends NonNullable;
+
+trait NonNullable;
+trait Nullable extends NonNullable;
+sealed trait DataValuePrimitiveType
+
+final class DataValue[+T <: AnyRef, +X<:AnyRef] private (val v: T) extends
AnyVal {
Review comment:
X is a phantom type. It is even less meaningful that the type variable T
(which could be called, say, UnderlyingType).
The purpose of X is to create a type hierarchy of the various type aliases I
define below.
In particular, it will allow us to define a type that can be any subset of
the support types.
For instance, I am currently using it to define:
* DataValueNonEmpty - which excluded DataValueEmpty
* DataValuePrimitive - which excludes DataValueDINode
We could also, define DataValueInteger, DataValueNumeric, etc.
This will allow us to add types in a limited context without while still
leveraging the type system to insure that they do not occur everywhere
DataValue is used.
For instance, we currently have that the "defaultVal" could be set to the
singleton object "UseNilForDefault".
When I get around to actually supporting that, we can define another type
that does not include UseNilForDefault as part of what it would allow.
We might find we can make useful distinctions between subsets of the types I
already have. I am hopeful I will at least be able to make the empty/non-empty
distinction useful. Not so confident that any other distinction will work out.
This whole sub-exercise might also turn into me wrestling with the
Scala/Java type system, in which case I will likely drop it.
----------------------------------------------------------------
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:
us...@infra.apache.org
With regards,
Apache Git Services
