Details
-
Improvement
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
2.5.0
-
None
Description
DPathCompileInfo should not be passed a RuntimeData to its constructor.
This causes a great deal of circularity between RuntimeData objects and computations that provide the values needed in those RuntimeData objects.
This prevents simplifying the constructors of the RuntimeData objects (DAFFODIL-2325), and causes them to hold onto large compile-time structures unnecessarily (DAFFODIL-1879)
Any computation that uses a check of an Evaluatable if it isConstant, (knownEncoding for example asks EncodingEv.isConstant), well.... constructing an evaluatable requires a DPathCompileInfo object, and ..... here's the problem: right now we pass a RuntimeData object to the DPathCompileInfo constructor purely for use compiling type-calc-related functions.
The type-calc functions need to know about sibling elements. The DPath compile info objects don't have sibling info. But the RuntimeData objects do. So that's where the expression compiler gets the sibling info it needs.
If some sibling information is needed to compile these functions, then we should compute that information and pass it to the DPathCompileInfo constructor, not just pass in the RuntimeData object.
Note however. The whole set of type-calc related functions is an experimental feature and subject to review. There are proposals to simplify it significantly. It's possible these functions will just not be needed. And in that case, the sibling info won't be needed in the DPathCompileInfo objects.
Attachments
Issue Links
- is related to
-
DAFFODIL-2273 Simplify Enumerations/typeValueCalc feature
- Closed