VehicleInterfaces icon indicating copy to clipboard operation
VehicleInterfaces copied to clipboard

Roads.Interfaces.Base functions are not constrained to be of the type declared in Roads.Interfaces

Open dariomangoni opened this issue 6 years ago • 5 comments

I have a doubt that, if you confirm, can be an issue.

Look at Roads.Interfaces.Base. There are 5 variables (position, trackOffset, etc...). These 5 variables are of type replaceable function thus can be replaced by any class that extends function.

The question is: is this the intended behaviour? Shouldn't these variable be constrained to be of type Roads.Interfaces.positionBase instead of the more general function? Shouldn't they be declared as
replaceable VehicleInterfaces.Roads.Interfaces.positionBase position;
for example?

dariomangoni avatar Jun 06 '18 14:06 dariomangoni

Well, to my knowledge this is a short form of class (function) definition, as described in Modelica Specification 3.4, Section 4.5.1. Thus

class IDENT1 = IDENT2 class-modification;

is identical to

class IDENT1
extends IDENT2 class-modification;
end IDENT1;

tobolar avatar Jun 06 '18 15:06 tobolar

Additionally section 7.3.2 (with anything in the Modelica specification you always need to cross-reference multiple sections!!) describes the "constraining-clause", for which the default is the declared type. Therefore for replaceable function position = VehicleInterfaces.Roads.Interfaces.positionBase the constraining-clause is VehicleInterfaces.Roads.Interfaces.positionBase.

A pattern that might be clearer would be to have default implementations of the functions and then explicitly declare the constraining-clause, as follows: replaceable function position = VehicleInterfaces.Roads.positionDefault constrainedby VehicleInterfaces.Roads.Interfaces.positionBase

This would make checking of the model(s) easier as the declared functions wouldn't be partial.

harmanpa avatar Jun 07 '18 08:06 harmanpa

This would require to define such "dummy" functions in Roads.Interfaces.Base or somewhere else. But the meaning of that functions would be ... well just a dummy.

tobolar avatar Jun 07 '18 11:06 tobolar

Absolutely they would be just a dummy, it's just a question of what is clearer, sometimes it's good to have a dummy implementation to copy. But it's just a case of style.

harmanpa avatar Jun 07 '18 12:06 harmanpa

OK, so question is rather how is a common solution of such an issue. Is there any similar case e.g. in Modelica Standard library?

If we go that way, the functions positionDefault, etc., could be defined for an ideal straight road. Thus, those functions would not necessarilly have to be replaced in a particular road model. For example, functions circleNormal and circleFrictionCoefficient could be omited in Roads.CircleRoad.

But it doesn't mean I prefer this solution ;-)

tobolar avatar Jun 07 '18 14:06 tobolar