clean up the ParentRef class
#136
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
this cleans up the internals of the `ParentRef` class to make it consistent with the information provided by the XML, use (IMO) slightly more descriptive names, changes the inheritance priority of ECU-SHARED-DATA from the highest to lowest (i.e., everbody can derive from it instead of nobody) and converts the class to be a dataclass to make it clearer which attributes are supposed to be available and slightly reduce the amount of boiler-plate code. In this context, note that the inheritance scheme which we implement is not 100% conformant with the specification: We allow a more specific (e.g., ECU-VARIANT) layer to inherit from any more generic layer (e.g., PROTOCOL), but the spec only allows to inherit from more generic layers that are once removed (i.e., BASE-VARIANT for ECU-VARIANT) plus from ECU-SHARED-DATA. Since we allow all inheritance possibilities of the spec (plus some more), I doubt that this will be a problem anywere except -- maybe -- for ODX editors build on top of odxtools... Signed-off-by: Andreas Lauser <andreas.lauser@mbition.io> Signed-off-by: Gerrit Ecke <gerrit.ecke@mbition.io>
kayoub5
reviewed
Jun 5, 2023
kayoub5
reviewed
Jun 5, 2023
andlaus
force-pushed
the
untangle_diaglayer_3
branch
from
ce92ff1
to
1a204e3
Compare
kayoub5
reviewed
Jun 5, 2023
kayoub5
reviewed
Jun 5, 2023
it was basically only used for an assertation. This check has now been moved to `DiagLayer`, and the inheritance priority of a diag layer is now defined by `DiagLayerType`. thanks to [at]kayoub5 for pointing this out! Signed-off-by: Andreas Lauser <andreas.lauser@mbition.io> Signed-off-by: Gerrit Ecke <gerrit.ecke@mbition.io>
…ind of parent layer this basically means the specialized PARENT-REFs (i.e., BASE-VARIANT-REF, PROTOCOL-REF, etc.) are kind of useless in the spec. thanks to [at]kayoub5 for wondering about this! Signed-off-by: Andreas Lauser <andreas.lauser@mbition.io> Signed-off-by: Gerrit Ecke <gerrit.ecke@mbition.io>
andlaus
force-pushed
the
untangle_diaglayer_3
branch
from
1a204e3
to
9023043
Compare
again, thanks to [at]kayoub5! Signed-off-by: Andreas Lauser <andreas.lauser@mbition.io> Signed-off-by: Gerrit Ecke <gerrit.ecke@mbition.io>
kayoub5
approved these changes
Jun 5, 2023
|
ok, let's get over this hump. thanks @kayoub5 ! |
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 cleans up the internals of the
ParentRefclass to make it consistent with the information provided by the XML, use (IMO) slightly more descriptive names, changes the inheritance priority of ECU-SHARED-DATA from the highest to lowest (i.e., everbody can derive from it instead of nobody) and converts the class to be a dataclass to make it clearer which attributes are supposed to be available and slightly reduce the amount of boiler-plate code.In this context, note that the inheritance scheme which we implement is not 100% conformant with the specification: We allow a more specific (e.g., ECU-VARIANT) layer to inherit from any more generic layer (e.g., PROTOCOL), but the spec only allows to inherit from more generic layers that are once removed (i.e., BASE-VARIANT for ECU-VARIANT) plus from ECU-SHARED-DATA. Since we allow all inheritance possibilities of the spec (plus some more), I doubt that this will be a problem anywere except -- maybe -- for ODX editors build on top of odxtools...
Andreas Lauser <andreas.lauser@mercedes-benz.com>, on behalf of MBition GmbH.
Provider Information