Clarification on modifying encapsulated classes

[eshmoylova]

I believe the encapsulated classes are not explained sufficiently well in the Specification (3.4 or the current master). In particularly, it is not clearly stated what happens to encapsulated classes when they are modified, extended, or redeclared. As a result different tools treat them differently, which is a reason for concern.

I tried to come up with all possible cases which I believe may or may not influence encapsulation status of the result in the following examples.

package P
    constant Real a = 5;

    function f
       input Real x;
       output Real y;
    algorithm
       y := x+a;
    end f;

    encapsulated model Source1
	connector OutPort = output Real;
	parameter Real p = 3;
	OutPort y = f(p*time); // Can be looked up in scope, but not globally
    end Source1;

 end P;

 package P2
    model Source2 = P.Source1;

    encapsulated model Source3 = .P.Source1;

    constant Real a = 2;
    encapsulated model Source4 = .P.Source1(p = a);
end P2;

package P3
    constant Real b = 7;
    extends P(Source1(p = b));
end P3;

model M
    parameter Real p = 4;
    P.Source1 s(p=p);
end M;

The encapsulated model P.Source1 contains a reference that can be found if searching in scope and should not be found if looking up in the global scope as you should for the encapsulated class. The other models are different ways to extend it and instantiate it. The question is which of them should produce an error. I tried three different tools and got three different results. The question came up when one of the user models used one of those constructs and the different results they get.

1. Simulating P.Source1 should give an error.
2. Should P2.Source2 give an error? It would appear that Source2 should not give an error because it is not declared as encapsulated. The content of P.Source1 should be brought into Source2. But should that content remember the scope it came from? It was encapsulated after all.
3. What if the extended class is declared as encapsulated like in the case of P2.Source3?
4. The question is also what happens if there are modifications. Modifications are defined in scope and technically should break the encapsulation of P2.Source4. As @HansOlsson brought up in this comment.
5. If modifications break the encapsulation rules how should the classes that are not directly extended but modified be interpreted like in the case of P3.Source1 and M.s?

This issue originally came up in #2623 but it looks to be a bigger issue that redeclaration alone.

[HansOlsson]

1. Agreed.
2. I would say that P2.Source2 should also give an error, since the class to be extended should first be instantiated normally and the encapsulation gives the same error as in 1.
3. I don't see that this changes anything.
4. I still think the comment hold. However, I realize that since modifiers are looked up in enclosing scopes for short-classes ( https://specification.modelica.org/master/class-predefined-types-and-declarations.html#short-class-definitions ) it may be that it is legal, but I would find that contrary to the idea of encapsulated.
5. Should be ok, as encapsulation is only for lookup inside the class and the modifiers are looked up externally.

[HansOlsson]

For item 4 the proposal would be:

An exception is that if the short class definition is declared as encapsulated, then the class-modifiers cannot be looked up in the enclosing scope.

[HansOlsson]

Agreement. (And will change 2 in Dymola.)