Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
dariomangoni opened this issue Jun 6, 2018 · 5 comments
Labels
L: Roads Issue concerns package Roads question Unexplained or undecided issue wontfix Issue that will not be fixed

Comments

@dariomangoni
Copy link
Contributor

dariomangoni commented Jun 6, 2018

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 dariomangoni changed the title Roads.Interfaces Base functions are not constrained to be of the type declared in Roads.Interfaces Roads.Interfaces.Base functions are not constrained to be of the type declared in Roads.Interfaces Jun 6, 2018
@tobolar
Copy link
Contributor

tobolar commented Jun 6, 2018

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
Copy link
Member

harmanpa commented Jun 7, 2018

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
Copy link
Contributor

tobolar commented Jun 7, 2018

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
Copy link
Member

harmanpa commented Jun 7, 2018

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 harmanpa added the question Unexplained or undecided issue label Jun 7, 2018
@tobolar
Copy link
Contributor

tobolar commented Jun 7, 2018

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 tobolar added the L: Roads Issue concerns package Roads label Sep 30, 2021
@tobolar tobolar added the wontfix Issue that will not be fixed label Jan 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
L: Roads Issue concerns package Roads question Unexplained or undecided issue wontfix Issue that will not be fixed
Projects
None yet
Development

No branches or pull requests

3 participants