modelica / VehicleInterfaces

Free (standard conforming) library for interface definitions and architectures for vehicle system modeling
Other
43 stars 22 forks source link

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

Open dariomangoni opened 6 years ago

dariomangoni commented 6 years ago

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?

tobolar commented 6 years ago

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;
harmanpa commented 6 years ago

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.

tobolar commented 6 years ago

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.

harmanpa commented 6 years ago

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.

tobolar commented 6 years ago

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 ;-)