Closed dariomangoni closed 3 years ago
Your idea is good. Thinking about, I only see two drawbacks.
includeXXXBearing=true
, the user could not directly recognise why usingMultiBodyXXX
is disabled. This could be solved by additonal comment in the parameter descripton and/or documentation. And it is probably better then the current situation.usingMultiBodyXXX
when developing his/her own model, i.e. being a developer. Properly, only includeXXXBearing
shall be used.yes, I think so; I think that is better that the user asks himself why usingMultiBodyXXX
is disabled and goes to the documentation, rather than leaving it available that does nothing. The user might indeed set usingMultiBodyXXX=true
and then could enable some includeBearingConnector
accordingly, thus being disappointed when the compiler warns against a connection of incompatible connectors.
that would cause a failure even now, wouldn't it? if the user-that-tries-to-become-a-developer would develop something it will then see that usingMultiBodyXXX
is not visible to the user and hopefully asks himself the same question as above!
The
usingMultiBodyXXX
parameters are always used in combination in an OR statement with their close friendsincludeXXXBearing
. Because of this, if the developer setsincludeXXXBearing
(that is protected) totrue
, automatically the user choice onusingMultiBodyXXX
will make no difference: because of the OR statement the logical results will always betrue
.Because of this, leaving
usingMultiBodyXXX
exposed to the user might mislead him to think that he can still disable the Bearings by settingusingMultiBodyXXX=false
while he actually cannot. Wouldn't be better to hideusingMultiBodyXXX
usingannotation(Dialog(enable=not includeXXXBearing))
?