JSON inheritance and copy-from¶
copy-from is not an implicit language feature shared by every JSON type. It works only when the
corresponding loader or factory implements inheritance, and types may have different merge and
validation rules.
The source-backed common skeleton¶
generic_factory looks for copy-from, resolves a parent object, and lets a type use a dedicated
handle_inheritance implementation or assignment copying. An abstract can act as an inheritance
template. Support for relative, proportional, extend, and delete depends on the type, the
field's C++ representation, and dedicated loader code.
That establishes three boundaries:
- Registration of a
typedoes not provecopy-fromsupport. copy-fromsupport does not prove support for all four incremental operations.- A loadable example for one type does not prove the same merge semantics for another.
The object-type registry locates loaders, but its current field
classification does not automatically prove complete inheritance behaviour. For an unclassified
entry, inspect whether its loader uses generic_factory, whether it implements
handle_inheritance, and which regression tests cover it.
Safe change procedure¶
- Locate the target
typeand loader in the registry. - Resolve the parent ID or abstract and the same-type constraint.
- Read that type's implementation of
copy-from,extend,delete,relative, andproportional. - Keep inheritance chains shallow and avoid undeclared cross-mod load-order dependencies.
- Test resolved values after real loading; do not compare input JSON text alone.
The item-name inheritance and monster attack-cooldown tests in tests/json_load_test.cpp show the
right testing layer: load data, then inspect the resolved object.
Compatibility¶
Changing a parent may change every descendant. Renaming or deleting a parent ID, changing a default, or changing replacement into extension can affect mods and saves. List descendants, run data loading and focused tests, and record JSON/mod documentation impact in the pull request.