Rename base classes with support flange

modelica / ModelicaStandardLibrary

Free (standard conforming) library to model mechanical (1D/3D), electrical (analog, digital, machines), magnetic, thermal, fluid, control systems and hierarchical state machines. Also numerical functions and functions for strings, files and streams are included.

https://doc.modelica.org

BSD 3-Clause "New" or "Revised" License

481 stars 169 forks source link

Rename base classes with support flange #3362

Open tobolar opened 4 years ago

tobolar commented 4 years ago

Due to similar model background, the following clases in Modelica.Mechanics.Rotational.Interfaces should be renamed:

PartialElementaryOneFlangeAndSupport2 to PartialOneFlangeAndSupportElementary (i.e. a counterpart of PartialOneFlangeAndSupport)
PartialElementaryTwoFlangesAndSupport2 to PartialTwoFlangesAndSupportElementary (i.e. a counterpart of PartialTwoFlangesAndSupport)

May be there is a better option for the supplement instead of "Elementary".

This concerns Modelica.Mechanics.Translational.Interfaces accordingly.

beutlich commented 4 years ago

We could rename it to PartialElementaryOneFlangeAndSupport/PartialElementaryTwoFlangesAndSupport (by simply removing the trailing "2"), but then there is some risk that someone using PartialElementaryOneFlangeAndSupport/PartialElementaryTwoFlangesAndSupport from MSL v3.2.3, who uses MSL v4.0.0 without conversion suddenly uses the wrong interface model.

beutlich commented 4 years ago

Here's the commit were the "2" models have been introduced: 68c3c517d1e344ba06ce10d00fbb7c7bc11ed787

dietmarw commented 4 years ago

Why not move non-2 ones to ObsoleteModelica4 and rename the 2-models? That way it should not break the interfaces.

beutlich commented 4 years ago

That's what already happened by 5b13d04eac91bbe56950b6fa2545b8e3388f8933. If we now introduce new models with that same name we might risk some name conflicts if conversion is either missed or run twice.

dietmarw commented 4 years ago

If we assume a conversion does not take correctly place then we have a whole lot of other problems. It would be strange to workaround that in this case. I'm sure if you look at this like that then we have a number of other cases that also need to be considered. I think it is safe to say that if conversion fails or is not done when using MSL 4.0.0 then user models will break.

tobolar commented 4 years ago

My intension is to give similar names to similar classes. Thus, the package content would be:

...
PartialOneFlangeAndSupport
PartialOneFlangeAndSupportElementary <-- PartialElementaryOneFlangeAndSupport2
PartialTwoFlangesAndSupport
PartialTwoFlangesAndSupportElementary <-- PartialElementaryTwoFlangesAndSupport2
...

I'm aware of the risk by leaving "2" only. This is not what I'm addressing here.

beutlich commented 4 years ago

But there still is PartialElementaryRotationalToTranslational, making it inconsistent.

tobolar commented 4 years ago

Hmm. This is true. Actually, this is even more confusing as PartialElementaryRotationalToTranslational has the same structure like PartialOneFlangeAndSupport or PartialTwoFlangesAndSupport. But it is documented to be intended for "equations in the text layer" and so is really used e.g. in IdealGearR2T. This additonally means:

PartialElementaryRotationalToTranslational shall be renamed to PartialRotationalToTranslational because this class uses internalSupport(s) and shall thus indeed be used for graphically given components. Even if such class would not be used anywhere in MSL now, it is necessary for proper conversion.
There should be defined a new class PartialRotationalToTranslationalElementary used for IdealGearR2T.

This is a lot more work but is consistent.