Redeclaring a derived class which has its own modifications

[Mahder Alemseged Gebremedhin]

I don't know if this has been reported before. If it hasn't
Consider this classes

class A
  class B
    Integer b1 = 1;
    Integer b2 = 2;
  end B;
  
  replaceable class C = B(b1=3);  
  C a1;
end A;

class D
  A d1(redeclare class C=E);
  class E
   Integer b1 = 4;
   Integer b2 = 5;
  end E;
end D;

OMC flattens this to

class D
  Integer d1.a1.b1 = 4;
  Integer d1.a1.b2 = 5;
end D;

Dymola flattens it to

model D
  Integer d1.a1.b1 = 3;
  Integer d1.a1.b2 = 5;
end D;

I checked the specification and it says

In redeclarations some parts of the original declaration
is automatically inherited by the new declaration. This
is intended to make it easier to write declarations by 
not having to repeat common parts of the declarations, 
and does in particular apply to prefixes that must be 
identical. The inheritance only applies to the 
declaration itself and not to elements of the declaration.

Are we doing this right? (I think we are).

[Per Östlund]

Dymola is correct in this case. C does not define a constraining type, so C itself becomes the constraining type. The modification (b1 = 3) should therefore be applied to any redeclaration of C, according to 7.3.2 in the spec (see the second example in that section for a similiar example to this).

[Mahder Alemseged Gebremedhin]

So

class D
  A d1(redeclare class C=E);
  class E
   Integer b1 = 4;
   Integer b2 = 5;
  end E;
end D;

and

class D
  A d1(redeclare class B=E);
  class E
   Integer b1 = 4;
   Integer b2 = 5;
  end E;
end D;

(if B is also replaceable)

should flatten the same. It is odd :)

[Per Östlund]

Since you've chosen Future as the milestone I'm assuming that it's not something that needs to be fixed right now, so I'm reassigning it to the new instantiation. If it's really important to fix this in the old instantiation, assign it to Adrian instead, he might take a look at it.

[Mahder Alemseged Gebremedhin]

Adrian is in the CC. I think it is up to you or Adrian when fix this. I have nothing that needs it right away.

Just FYI Per, I looked for "constrainedby"s in MSL 3.2. The only places it is used is in Media, Fluid and Mechanics.Multibody. So I am assuming somewhere in there should be some code similar to this case. Maybe it is one of the reasons for OMC's problem with this libraries.

[Per Östlund]

Replying to mahge930:

Just FYI Per, I looked for "constrainedby"s in MSL 3.2. The only places it is used is in Media, Fluid and Mechanics.Multibody. So I am assuming somewhere in there should be some code similar to this case. Maybe it is one of the reasons for OMC's problem with this libraries.

None of the uses of constrainedby in the MSL seems to declare any modifiers on the constraining class, so I don't think this is an issue.

[Adrian Pop]

I think I have fixed this in my local copy since December by merging all modifiers on the redeclare chain.
The problem is that it breaks some of the other tests, mostly ones where the the modifier appearing on the leaf class does not exist anymore in the class given in the redeclaration.
I have an idea how to handle this and I'll try it. If it works fine I'll push my changes.

[Francesco Casella]

Issue is still valid with the NF as of v1.13.0-dev-672-g87286cb84

[Francesco Casella]

Issue is still valid with NF as of v1.13.0-dev-798-g1c8bb86de

[Per Östlund]

Both the new and the old frontend now gives:

class D
  Integer d1.a1.b1 = 3;
  Integer d1.a1.b2 = 5;
end D;

The issue was fixed in the new frontend in 336df19d, no clue when it was fixed in the old.