-
Notifications
You must be signed in to change notification settings - Fork 42
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
Multiple modifications and merging of modifications. #3474
Comments
Here are other, weird cases:
|
Should there be a difference between the following models:
|
Great, I managed to write a detailed reply and then close the window before commenting and then I lost power... Here the tests go again in Dymola:
The issue for Test4, Test5, and Test6 is that Dymola for some reason doesn't handle the implicit "redeclare" for these replaceable components (so if you use
Clearly it doesn't make sense to keep the modifier and use it with an incompatible class. |
SimulationX; |
I believe I have found a good reason why we shouldn't handle the double modification in Test(1). Consider the following variants of Test5A:
That model gives c.x=2, (swapping A1 and A2 wouldn't influence this result). If we want to merge A1 and A2 into one class that seems to have modifier
but then Since merging a value-modifier with A working way to combine the redeclaration and the modifier is:
It is a bit esoteric (since the use-case is esoteric), but it clearly indicates the differences. The only down-side is that it is necessary to repeat the constrainedby-class. |
Given how modifications work the |
Does that mean that there's agreement on all issues? In that case the next question is whether we need to change something in the specification. |
I agree on the results. The first version I tried for Test4, Test5, Test6 gave the same result as in Dymola. But I found that there was a bug that we were merging modifications from an outer redeclaration with an inner redeclaration. I am not sure that the point that modifications from an intermediate redeclaration is dropped with a subsequent redeclaration is made clear in the specification. The only reference that I see to it is in the comment about T0 in the example of Circuit3. And it took some purposeful searching to find that. As for the double modifications in Test(1), if |
As indicated above I believe we need to specify that due to the different between default for the replaceable component, and default for its constraining type. We should likely have an example as well for this. |
Looking through the options here. To me it makes the most sense that Note that However, I agree that it is awkward and would propose:
where the part after "|" is new. This allows directly writing Some design considerations:
I tried to look at constrainedby in MSL and only found the following case that could be simplified:
The following cases could just drop the constrainedby:
|
Phone meeting: An alternative is to interpret it as |
Hmm.. Thinking more I realized that there are two other cases: If we have: To me this indicates that we should just report it as an error at the moment, and make that clear in the specification.
|
WSM finds |
Dymola doesn't do that, and thus I think it is best to not define that as different tools have different opinions and it seems better that users clarify their intent. BTW: Do I understand it correctly that you interpret |
I misremembered during the meeting, both cases are handled the same, as you see it My way of seeing it is that we handle the modifications in the same way we would if they came from different scopes, except for the usual case where
If there is a strong consensus among the different tools, I would much rather go with that interpretation than forbidding it because it wasn't unanimous. |
But how does that work if you start from Is it just internally handled in that way - as the Base-class isn't known, or is there some additional trick? |
I don't understand the question. I am not sure there are additional tricks, but I did find the whole thing, extremely tricky to implement. |
Ok, I see. The problem is then that the current specification describes the handling of such modifiers as a form of syntactic sugar for the merged variant, and in this case it is impossible if there is no constrainedby. Obviously we don't have to describe it as syntactic sugar in all cases (or even at all), so I guess the suggestion would instead be to just describe how the nested modifiers are handled. See proposal in #3545 |
I think there are some corner cases in the handling of modifications where we need some explicit clarifications.
#3339 contains some examples.
Here are a few more models:
I would consider all of them valid, and after resolving the modifications, I would expect:
Test.a.x.start = 2
Test2.a.x.start = 2
Test3.a.x.start = 2
What do other people think?
The text was updated successfully, but these errors were encountered: