Clarification on matching relative order between package.mo and package.order

[eshmoylova]

I just submitted an issue against MSL about mismatching order between package.mo and package.order. I would like to confirm the meaning of the following in the specification:

Classes and constants that are stored in package.mo are also present in package.order but their relative order should be identical to the one in package.mo (this ensures that the relative order between classes and constants stored in different ways is preserved).

To keep the relative order, we need to keep classes from package.mo together, right?

For example, if in package.mo we have (in order of appearance):

package PA
  class A...
  extends P;
  class C...
end PA;

And separately there is B.mo, and package.order is defined as:

A
B
C

Is it considered that package.order satisfies the quoted requirement from the specification? A is still ahead of C as in package.mo.

Assume also that P also has some classes and constants defined in it. So, if it is considered that the requirement is satisfied, and we only worry about A and C being relative to each other, where would you put B with respect to the extends clause?

[maltelenz]

Is it considered that package.order satisfies the quoted requirement from the specification? A is still ahead of C as in package.mo.

I interpret this as being fine.

Assume also that P also has some classes and constants defined in it. So, if it is considered that the requirement is satisfied, and we only worry about A and C being relative to each other, where would you put B with respect to the extends clause?

I would put the extends in a special extends display :). This is how System Modeler displays it (I expanded all the trees in our Class Browser):

Or you can look at PackageSort.PA in the text view, where it will look like this:

package PA
  model A
  end A;

  extends P;

  model B
  end B;

  model C
  end C;
end PA;

Edit: I guess I see your point, it could also look like this in the text view:

package PA
  model A
  end A;

  model B
  end B;

  extends P;

  model C
  end C;
end PA;

In the end, does it matter?

[HansOlsson]

I just submitted an issue against MSL about mismatching order between package.mo and package.order. I would like to confirm the meaning of the following in the specification:

Classes and constants that are stored in package.mo are also present in package.order but their relative order should be identical to the one in package.mo (this ensures that the relative order between classes and constants stored in different ways is preserved).

To keep the relative order, we need to keep classes from package.mo together, right?

I would say no, and only require that the common sub-set has the same order in both.
(And of course that package.mo contains a sub-set of package.order.)

For example, if in package.mo we have (in order of appearance):

package PA
  class A...
  extends P;
  class C...
end PA;

And separately there is B.mo, and package.order is defined as:

A
B
C

Is it considered that package.order satisfies the quoted requirement from the specification? A is still ahead of C as in package.mo.

I would say so. However, a minor concern is that we don't have a way of specifying the order of extends-clauses; so we can't way whether it should be "A B extends P; C" or "A extends P; B C". In practice that isn't that important as extends-clauses in packages are normally at the top, and usually only for the package-Icon (possibly except for Media-packages, but there are a number of issues with splitting them into different files).

[HansOlsson]

In the end, does it matter?

I don't think the order in the text matters much.

However, in Dymola we also allow mixing extends-clauses with normal classes in the package-browser, so I guess that could give a different view and some would be confused, but people normally put the extends-clauses first and in that case it just works.

An exception to that order is Modelica.Media.Water.ConstantPropertyLiquidWater - but the rules wouldn't matter as it's stored with the enclosing Water-package and the other element is a constant that cannot be stored in a separate file.

[eshmoylova]

Well, it just happened so, that I got a library from a user with an extends clause that brought some extra elements and was not sitting at the top of the package.

But even if it was at the top of the package, and we allow mixing classes from package.mo and other classes, where would you put that extends clause? At the very top, or just ahead of the elements that come from package.mo? To me the whole requirement of having relative order preserved is that it would also keep the relative order of extends clauses in the right place. And the only way it is possible is if the whole content of package.mo is kept together. Otherwise, why do we need the requirement that the relative order of package.mo should be the same as in package.order?

[HansOlsson]

To discuss:

• Is definition of relative order unclear?
• Is it necessary to add extends-clauses to package.order?

[HansOlsson]

Language group: A bit unclear - try to add extends-clauses and clarify.