MCP0032: Added summary of the discussions and decisions of the 99th M…

…odelica Design Meeting.

RationaleMCP/0032/minutes.md

@@ -12,4 +12,20 @@ The following list compiles minutes of all official events and discussions - lik
 - **Decision (discussion):** No support for fine-grained connection deselection (i.e. removing only parts of a connection).
 - **Decision (poll):** Use `break` as keyword like proposed in the Modelica 2019 conference paper; also use the same syntax for component and connection deselections (i.e., `break component-name` and `break connect(first-connector, second-connector)`).
   - Other suggestions, instead of `break`, have been `not`, `remove`, `ignore`, `redeclare Type component-name if false` after component, `notPresent`, `deselect`, `without`, `undeclare`, use new character `$ignore component-name` or use some new function syntax.
-  - Advantage of `break` is that it does not introduce a new keyword; its backward compatibility outweighs gain of readability. `break` is readable enough.
+  - Advantage of `break` is that it does not introduce a new keyword; its backward compatibility outweighs gain of readability. `break` is readable enough.
+
+## 99th Modelica Design Meeting
+
+- [Original minutes](https://svn.modelica.org/projects/ModelicaDesign/trunk/MeetingMinutesMaterial/min99_2019_Linkoeping/)
+
+- **Decision (discussion):** No need to support deselections within `long-class-specifier`. Support deselection only within `extends-clause`.
+
+- **Decision (poll):** Only allow deselections _directly_ inside `extends-clause`, i.e., only as top-level/non-nested modification. This should be specified in terms of the context-free grammar of the Modelica specification, not as semantic rule. No ordering of modifications should be enforced; ordinary- and inheritance-modifications (deselections) can be in arbitrary order as long as inheritance modifications are top-level modifications.
+
+  - **Rationale why only top-level inheritance modifications:** Defining the semantics of nested deselection modifications or supporting such is not a problem. But to be useful, it also has to be possible to add elements in terms of nested modifications; otherwise, deselecting connections of a nested sub-component will, for example, most likely result in non-fixable singular equation systems. In the long run, it therefore would be good to add both, (1) language means for adding elements to nested sub-components within modifications and analogous (2) deselecting nested sub-components.
+
+  - **Rationale why modification order doesn't matter:** Modelica is declarative; it is a general objective of the Modelica language design that order doesn't matter.
+
+- **Decision (poll):** For connection deselections, the order of the `connect` arguments does not matter; `break connect(a, b)` deselects the connection between `a` and `b` regardless if it is defined as `connect(a, b)` or `connect(b, a)` in the selectively extended base-class.
+
+  - **Rationale why order of `connect` arguments doesn't matter:** Modelica is declarative; it is a general objective of the Modelica language design that order doesn't matter. Also, a base-class refactoring just switching the order of a connection's arguments should not break existing deselections in models selectively extending the base-class.