Hi, the first example from Kilian is well-defined: component in Subpackage1.test enshadows component in Subpackage1. Classic scoping rules. The example from Adrian is quite interesting: Modelica as is does not distinguish between type names and those of components. Unfortunately the "double definition forbidden" rule is a little bit unclear here. So it is not clear currently wether the example is correct Modelica or not (I tend to the latter).
Am Freitag, den 19.11.2010, 19:05 +0100 schrieb Adrian Pop: > Hi all, > > I agree that OpenModelica is rather drastic here > and generates a warning if the last name in the > type specifier is the same as the name of the > component. We could relax this check to display > the warning only if the type specifier points > to the same scope as the scope of the component > (see example below). > > You still may have a problem if > Package1.Subpackage1.component > points to a class in the same > scope as component, i.e: > > package Package1 > package SubPackage1 > // a type > type component = Real; > // a component with the same name > Package1.SubPackage1.component component; > end SubPackage1; > end Package1; > > Truth is that we need better naming guidelines for Modelica code. > I would say that the name of a type, class, block, model should > begin with big letter followed by small letters. So the default > names that Dymola generates for models are a bit off. > Well, when you think about functions, in general they should > begin with small letter, so guidelines are a bit strange. > > We should discuss the code guidelines at the > Modelica Design Meeting to come up with something > that can be specified in the Modelica Specification > so is used in all tools to have the code we generate > a bit more homogeneous. > > Cheers, > Adrian Pop/ > > On 2010-11-19 16:56, Link, Kilian (E F ES EN 1 2) wrote: > > Dear OpenModelic interested, > > lately we ran into a problem with interpretation of naming rules in the > > Modelica Standard. Or more precise: The default naming of components in > > Dymola is not accepted by omc. > > Consider the following structure, generated using Dymolas drag and drop > > facilities and its defaulf naming. > > package Package1 > > > > package SubPackage1 > > > > model component > > > > end component; > > > > end SubPackage1; > > > > model test > > > > SubPackage1.component component; > > > > end test; > > > > end Package1; > > > > Compilation with omc gives the warning: > > Warning: Component component has the same name as its type > > Package1.SubPackage2.test.SubPackage1.component. > > This is forbidden by Modelica specifications and may lead to lookup errors. > > According to the Dymola support: > > The "type specifier is 'Package1.Subpackage1.component' and that is > > different from 'component' so that is ok." > > My problem here is that the suitabality of Modelica to be a tool > > independ standard has to changelled if tools behave such different. > > > > With best regards, > > Kilian Link > > > > Siemens AG > > Energy Sector > > Fossil Power Generation Division > > Energy Solutions > > E F ES EN 1 2 > > Freyeslebenstr. 1 > > 91058 Erlangen, Germany > > Tel.: +49 (9131) 18-6634 > > Fax: +49 (9131) 18-6471 > > mailto:[email protected] > > > > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard > > Cromme; Managing Board: Peter Loescher, Chairman, President and Chief > > Executive Officer; Wolfgang Dehen, Brigitte Ederer, Joe Kaeser, Barbara > > Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen; Registered > > offices: Berlin and Munich, Germany; Commercial registries: Berlin > > Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 > > > >
