Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enforce unique MacroStaticReference for each dynamic model #112

Closed
flo-dup opened this issue Jul 6, 2022 · 3 comments
Closed

Enforce unique MacroStaticReference for each dynamic model #112

flo-dup opened this issue Jul 6, 2022 · 3 comments

Comments

@flo-dup
Copy link
Contributor

flo-dup commented Jul 6, 2022

  • Do you want to request a feature or report a bug?
    Feature

  • What is the current behavior?
    Nothing ensures that a model has the same MacroStaticReference for all of his instances. Only one is kept for all instances when dyd is written, as it is indexed in the corresponding map by the lib name.

  • What is the expected behavior?
    One model has the same MacroStaticReference for all of his instances

  • What is the motivation / use case for changing the behavior?
    Having by design a unique MacroStaticReference for each dynamic model

@flo-dup
Copy link
Contributor Author

flo-dup commented Jul 6, 2022

The benefit of current approach is that, when adding a new model, everything is done in the same new class.

We could enforce by design that uniqueness by delegating this role to a MacroStaticReferenceProvider, which would provide a MacroStaticReference based on a Class<? extends BlackBoxModel>, but then we're loosing that aforementioned benefit and the benefit of inheriting getVarsMapping definition when defining a new model which inherits from another.

@flo-dup
Copy link
Contributor Author

flo-dup commented Jul 6, 2022

Similar issue exists for MacroConnector. For which we also loose the benefit of BusModel / GeneratorModel / LineModel interfaces, which make it easier to define everything needed when adding a new model hence new possible connections.

dimbdr pushed a commit that referenced this issue Nov 7, 2022
…cRef (#112)

By design, all instances of one class derived from AbstractBlackBoxModelWithStaticRef implements getMacroStaticReference, and gives a unique MacroStaticReference according to the implementation of the target class.
Note: still need to clean some class dependencies (see the modification in AbstractNetworkBlackBoxModel). It shouldn't be implemented.

Signed-off-by: BAUDRIER Dimitri <dimitri.baudrier@rte-france.com>
dimbdr pushed a commit that referenced this issue Nov 8, 2022
…cRef (#112)

By design, all instances of one class derived from AbstractBlackBoxModelWithStaticRef implements getMacroStaticReference, and gives a unique MacroStaticReference according to the implementation of the target class.
Note: still need to clean some class dependencies (see the modification in AbstractNetworkBlackBoxModel). It shouldn't be implemented in classes that doesn't support varmappings.

Signed-off-by: BAUDRIER Dimitri <dimitri.baudrier@rte-france.com>
dimbdr pushed a commit that referenced this issue Nov 17, 2022
…cRef (#112)

By design, all instances of one class derived from AbstractBlackBoxModelWithStaticRef implements getMacroStaticReference, and gives a unique MacroStaticReference according to the implementation of the target class.
Note: still need to clean some class dependencies (see the modification in AbstractNetworkBlackBoxModel). It shouldn't be implemented in classes that doesn't support varmappings.

Signed-off-by: BAUDRIER Dimitri <dimitri.baudrier@rte-france.com>
dimbdr pushed a commit that referenced this issue Nov 18, 2022
…cRef (#112)

By design, all instances of one class derived from AbstractBlackBoxModelWithStaticRef implements getMacroStaticReference, and gives a unique MacroStaticReference according to the implementation of the target class.
Note: still need to clean some class dependencies (see the modification in AbstractNetworkBlackBoxModel). It shouldn't be implemented in classes that doesn't support varmappings.

Signed-off-by: BAUDRIER Dimitri <dimitri.baudrier@rte-france.com>
@dimbdr dimbdr linked a pull request Dec 1, 2022 that will close this issue
1 task
@flo-dup
Copy link
Contributor Author

flo-dup commented Sep 11, 2024

Won't fix

@flo-dup flo-dup closed this as not planned Won't fix, can't repro, duplicate, stale Sep 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant