...
Much of the code does not follow these guidelines. As it evolves the goal is to make new code follow these guidelines, and to evolve existing code toward them.
See also Performance Coding for Runtime
64-bit vs. 32-bit
Our goal is all-64-bit capabilities. Unfortunately, many Java and Scala libraries do not allow offsets or positions larger than a signed 32-bit Int can hold.
...
* Except perhaps Saxon which is still the no-longer-progressing Saxon-B, which is fine for now. (Note: No longer using Saxon as of late 2014.)
Use Smaller Files
Scala's compiler is quite slow, and an this must be taken into account to insure a reasonable edit-compile-debug cycle for developers. A compilation unit is an entire file. Incremental compilation is improved in efficiency if the files are smaller. So avoid huge files that blend multiple concepts together. Do not, however, go so far as to break things apart that really are best understood if kept in the same file.
...
The convention is to begin the identifier with either bit, byte, or char, (or other like 'child'), and suffix it with 1b or 0b.
Examples:
- bitPosition0b : ULong - means position, measured in bits, first bit is at position 0, type unsigned long.
- mCharWidthInBits: MaybeInt - measured in bits, but note that sizes, lengths, widths, don't have 0 or 1 base stuff. Note also use of MaybeInt type.
- childIndex1b - child index, first child is at index 1.
Exercise for Reader! Create a scala ZeroBased and OneBased AnyVal wrapper type with explicit (or some implicit) conversions. So the type of bitPosition0b (which is ULong currently) would be
| Code Block |
|---|
var bitPosition0b = ZeroBased[ULong]
var bitPosInByte1b = OneBased[UInt] |
Identifier Naming Conventions
...
This library has been tried and we may still use it to assemble lists of schema files for us, so that it will handle the namespace resolution and include/import. But we have tried and found it unusable as far as abstract access to the DFDL Schema objects. Specifically, it does not have a first-class notion of a Schema Document. DFDL depends heavily on the notion of a Schema Document in that these are the units where lexically-scoped annotations are used. XSOM provides no way to even ask for the annotations on a schema document, so one cannot implement DFDL's lexical scoping feature using XSOM.I