Get rid of 'protected'

[henrikt-ma]

No description provided.

[olivleno]

Web Meeting: Hans, Henrik, Gerd, Martin, Oliver

Uses of protected in Modelica:

• restrict connection (does not apply in flat Modelica)
• restrict modification (should be checked by the full Modelica tool)
• exclude from results (vendor specific heuristic, hideResults=true)
• prevent access via dot notation (should be checked by the full Modelica tool)
• local variables in functions

Example:

function f
  input Real u;
  output Real y;
protected
  Real x;
algorithm
  x := u+1;
  y := x*x;
end f;

flat Modelica w/o protected

function 'f'
  input Real 'u';
  output Real 'y';
  Real 'x';
algorithm
  'x' := 'u'+1;
  'y' := 'x'*'x';
end f;

The fact that x is not part of the function interface is also clear w/o protected.

Conclusion:
There is no need for protected for functions or any other case listed above.

Open question:
Can we also remove public?

[olivleno]

Web Meeting: Hans, Henrik, Gerd, Martin, Oliver

Henrik: If we can handle final, then we can protected also, because restricted modifications. In terms of heuristics we will have to see.

Henrik: public is needed only to end a protected section. If we don't have protected there is no need for public.

Hans: There are heuristics using them. Adding an annotation may add so much more. Maybe we need to have an appropriate semantics for protected, then the heuristics could remain.

Henrik: To this would be cleaner to keep only what is needed.

Hans: It doesn't hurt keeping it.

Henrik: Having a keyword but a different semantics will be confusing.

Henrik: Keeping public and protected may lead to alternating sections.

What are these heuristics?

• Determine what to store
  • storeResults=true/false is not sufficient, would have to be extended to preserve the information that it was protected.
• Equation system tearing
  • It makes sense to give start values only to public variables.
• Alias elimination
  • Keep the non-protected variables to make it easier to understand.

Keep the information that a start value cannot be modified would make the selection for tearing more transparent.
This is comparable to final modification of start.

Proposals:

1. Keep keywords public and protected but remove semantic restrictions.
2. Find annotations for storing results and alias elimination and use it also for tearing if needed.
3. Add an annotation protected=true and don't require protected for local variables inside functions.

Poll:

Option 1: None.
Option 2: Oliver
Option 3: Henrik, Gerd, Hans
abstain: Martin

Decision:
Go with option 3.
Update the PR [Henrik]

[HansOlsson]

I believe we should use a longer example:

  model M
     Real x;
  protected
     Real p;
  end M;

  model N
    M m1;
  protected
    M m2;
  end N;

  // Flat
  Real 'm1.x';
  Real 'm1.p' annotation(prot=true); 
  Real 'm2.x' annotation(prot=true); 
  Real 'm2.p' annotation(prot=true); 

[olivleno]

Web Meeting (Hans, Henrik, Gerd, Martin, Oliver)

Added the "long" example from Hans to the annotations.md

Decision:
The fact that the hierarchical information about protected sections is lost is accepted.

[casella]

A post-mortem comment here. I understand it is well settled in the current proposal that protected is not need in BaseModelica functions, all non-input, non-output variables are considered as local variables of the function, although this actually makes BaseModelica functions invalid in Modelica. BTW, I never fully understood why we require to put protected before non-input non-output in Modelica and complain , but that is another story. My question regards the paper presented in Aachen, where I see:

I guess the protected keyword was put there by mistake, can you please confirm?

Thanks!

[henrikt-ma]

Well spotted! The text for constsize must be older than the decision to remove protected, and then we made the mistake of copying code into the paper without looking at it carefully. I'll set up a PR to at least get it fixed on the MCP branch.