Online edition for BLOGE
0.9.9-RC1· prepared 2026-11-02 · 中文
Appendix G — DSL Engineering Reference
Chapter 8 teaches how a personal draft becomes a team asset. This appendix keeps engineering lookup detail out of that first-reading path.
Imports and aliases
Prefer an explicit alias:
import "./payment-flow" as paymentFlow
Without one, the compiler may derive a name from the final path segment. Team-owned files should still declare it so renaming a file does not silently rename every reference. FileSystemGraphResolver resolves relative paths from the current file. Missing files, cycles, and duplicate aliases are graph-construction errors.
Schema lookup
| Fact to express | Form |
|---|---|
| Required scalar | field: String |
| Optional scalar | field: String? |
| Reused shape in one file | named schema |
| One-off local shape | inline { ... } |
| Homogeneous collection | List<T> |
| Key/value shape | Map<K,V> |
RC1 path validation can diagnose each segment of an inline nested shape. The ch08 probe therefore uses an inline customer; do not turn this observation into a promise about every future release.
ValidatedSchema is not DSL syntax
The Java runtime can combine an expected schema with STRICT, COERCE, or LENIENT policy through ValidatedSchema. The DSL compiler reads the expected schema for structural checks; runtime policy decides how values are validated or converted. Keep the claims separate: a correct compile-time path does not prove that a runtime value satisfies policy.
Resolver extension boundary
A custom GraphResolver may load graphs from a controlled repository, classpath, or another versioned source. It should provide deterministic identity, explicit failure, and cycle protection. Remote fetching, cache invalidation, and signature validation remain host-system responsibilities; import syntax does not provide them automatically.