Untangle diaglayer (Part 6) #145
Merged
Conversation
This file contains 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
Signed-off-by: Andreas Lauser <andreas.lauser@mbition.io> Signed-off-by: Gerrit Ecke <gerrit.ecke@mbition.io>
Signed-off-by: Andreas Lauser <andreas.lauser@mbition.io> Signed-off-by: Gerrit Ecke <gerrit.ecke@mbition.io>
Signed-off-by: Andreas Lauser <andreas.lauser@mbition.io> Signed-off-by: Gerrit Ecke <gerrit.ecke@mbition.io>
This puts the sub-objects of DATA-DICTIONARY-SPEC in the same place as where they can be found in the XML and the raw diaglayer. e.g., the data object properties are contained by `.data_dictionary_spec` instead of being directly helt by the DiagLayer. (Whether using DIAG-DATA-DICTIONARY-SPEC makes much sense in the first place is a different matter IMO...) Signed-off-by: Andreas Lauser <andreas.lauser@mbition.io> Signed-off-by: Gerrit Ecke <gerrit.ecke@mbition.io>
`DopBase` is the base class for `DataObjectProperty` and `DtcDop`, but usually only one of these can be specified. Signed-off-by: Andreas Lauser <andreas.lauser@mbition.io> Signed-off-by: Gerrit Ecke <gerrit.ecke@mbition.io>
this method behaves like any other comparam-wrapper function: it returns None if the comparam has not been specified... Signed-off-by: Andreas Lauser <andreas.lauser@mbition.io> Signed-off-by: Gerrit Ecke <gerrit.ecke@mbition.io>
`repr()` was quite incorrect, as as this method is intended to return a full representation of the object as a string (e.g. how an equivalent object can be constructed), which is quite unpractical because for `DiagLayer` this would often result in a string with a length of several million of characters. Signed-off-by: Andreas Lauser <andreas.lauser@mbition.io> Signed-off-by: Gerrit Ecke <gerrit.ecke@mbition.io>
kayoub5
reviewed
Jun 19, 2023
kayoub5
reviewed
Jun 19, 2023
this makes things easier to read and fixes the formatting which got mangled due to now exposing DOPs via the `diag_data_dictionary_spec` sub-object of diaglayers. thanks to [at]kayoub5 for the proposal. Signed-off-by: Andreas Lauser <andreas.lauser@mbition.io> Signed-off-by: Gerrit Ecke <gerrit.ecke@mbition.io>
kayoub5
approved these changes
Jun 20, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR collects various smaller fixes for the diaglayer code (in that sense, it consists purely of "drive-by" fixes). The most notable of those changes is that the "logical" view now exposes all objects that are contained by the DIAG-DATA-DICTIONARY-SPEC tag using a separate
.data_dictionary_specattribute instead of providing e.g. the.data_object_propertiesdirectly. (This is not completely trivial because some of the sub-objects of the diag data dictionary spec are subject to value inheritance).Andreas Lauser <andreas.lauser@mercedes-benz.com>, on behalf of MBition GmbH.
Provider Information