Support type designators that are also key slots#3
Merged
Conversation
A type designator slot may also be the key (or even the identifier) slot
if its class. Combined with dict inlining, this can be used to do
something like this:
items:
FooItem:
# ... FooItem attributes
BarItem:
# ... BarItem attributes
BazItem:
# ... BazItem attributes
where FooItem, BarItem, and BazItem are all subclasses of Item (which is
the declared range of the `items` slot), and the keys of the `items`
dictionary act both as identifiers to refer to one particular item,
_and_ as type designators to indicate the precise type of each item (as
a side-effect, this ensures that `items` can only contain one object of
each type).
This is a pattern that could be useful for NGMF and/or NGFF extensions,
and that we should support.
This commit adds an explicit test case for it. The test currently
_fails_, because the ObjectConverter does not expect to find the type
designator as the key in a "inlined-as-dict" object.
Support the case where a type designator slot is also the key slot of its class. The fix to support that case is 3-fold: (1) The constructor of ClassInfo must explicitly allow a slot to be both a key slot and a type designator slot (currently, once a slot has been recognised as a key slot, it can no longer be recognised as a type designator). This is the only needed fix for _deserialisation_. Support for _serialising_ an instance of a class that has a dual key+type designator slot further requires: (2) The existing logic in the ObjectConverter class to find the most precise converter to use, which is currently only applied in some cases, must be used systematically. For that, it is moved at the beginning of the main `serialise(Object, boolean, ConverterContext)` method. (3) We must (temporarily) forbid inlined as a "simple dict" for any class that has a type designator, even if it has only a key slot and a primary value slot. This is because we cannot easily know if all subclasses will also be eligible for "simple dict" inlining.
Test that we can correctly handle the case of a unknown designated type (where the type referenced by the type designator, which also happens to be the key of the dictionary entry, does not correspond to a known class in the code).
When serialising, we must be ready for the case where the object to serialise may not have its type designator slot set to a value. We already support that in the general case, but some additional support is needed for the special case where the type designator slot also happens to be the key slot of its class.
When the range of a multi-valued slot is a class that has descendants, it can happen that some objects in the list are eligible for simple dict inlining whereas some others are not (if the base class has only two slots but some derived classes have some additional slots). We already support that case when deserialising (this is automatically taken care of by the ObjectConverter::normalistList method), this commit makes sure we also support that case when serialising. All that is needed is to check for simple dict eligibility separately for every single object in the list to serialise, instead of once and for all at the beginning of the serialisation.
A kind of "special case within a special case" is the case where the type designator slot also happens to be, not the _key_ slot, but the _identifier_ slot of its class. This is already fully supported by the existing code, but we add a test fixture to explicitly test this case.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A type designator slot may also be the key (or even the identifier) slot if it's class. Combined with dict inlining, this can be used to do something like this:
where FooItem, BarItem, and BazItem are all subclasses of Item (which is the declared range of the
itemsslot), and the keys of theitemsdictionary act both as identifiers to refer to one particular item, and as type designators to indicate the precise type of each item (as a side-effect, this ensures thatitemscan only contain one object of each type).This is a pattern that could be useful for NGMF and/or NGFF extensions, and that we should support.
For now, this PR adds an explicit test case for it. The test currently fails, because the ObjectConverter does not expect to find the type designator as the key in a "inlined-as-dict" object.