RE: Re: dynamics: comment about MBdyn...

> From: Herman Bruyninckx [mailto:[email protected]]
> Subject: RE: [Orocos] Re: dynamics: comment about MBdyn...
> 
> 
> On Wed, 16 Jul 2003, Tiller, Michael (M.M.) wrote:

> [...]
> > other words, you can use the factory pattern in Modelica (my group
> > uses it in a couple of different ways in fact).  It is a pretty
> > advanced idiom in Modelica, but the language definitely supports it.
> 
> There is a big difference between _supporting_ something, and
> _promoting_ or _enforcing_ something. Modelica supports in principle
> anything, because there is this undefined "annotation" statement...

Just to be clear, this feature has nothing to do with annotations.  I find your position rather strange since everything in the patterns book is an idiom...none of them are directly supported of enforced by the language?!?

> > Here is a simple example:
> > 
> > package PartsFactory
> >   partial model RevoluteJoint
> >   end RevoluteJoint;
> >   partial model InertiaBase
> >   end InertiaBase;
> >   partial model Link
> >   end Link;
> > end PartsFactory;
> > 
> [...]
> > model MyRobot
> >   replaceable package Factory=SimplePartsFactory extends 
> PartsFactory;
> >   Factory.RevoluteJoint joint;
> >   Factory.InertiaBase base;
> >   Factory.Link link;
> > equation
> >   connect(joint,link.a);
> >   connect(base,link.b);
> > end MyRobot;
> > 
> [...]
> > Keep in mind I'm just typing this in off the top of my head so I
> > probably made a few mistakes.  The point is to convey the concepts.

> No problem with the syntax :-) But in my opinion, a real Factory does
> more than what you describe: it should perform checks during
> construction. (Of course, I guess it is difficult to enforce these
> checks in a file format.)

I still feel like you are still not quite understanding the implications here.  Modelica isn't just a file format.  As I keep saying, there are semantic implications when I write these things.

In short, It does perform checks!

There are subtype requirements that are implied in the semantics of the language.  The original factory defines what the interface is for the RevoluteJoint, InertiaBase and Link classes will be.  It happens that in my example I didn't include anything in the interfaces, but if I did, all factories would be required to provide implementations that were subtypes that supported the original interfaces.

> So, what I meant in a previous email is that
> the sequence of constructors
>    Factory.RevoluteJoint joint;
>    Factory.InertiaBase base;
>    Factory.Link link;
> would not be allowed to happen without the connections
>    connect(joint,link.a);
>    connect(base,link.b);
> Using your example, I would prefer to see something like this
> (violating the Modelica syntax, I know):
>   Factory.InertiaBase base;
>   Factory.Link link; connect(base,link.b);
>   Factory.RevoluteJoint joint; connect(joint,link.a);
> The difference with your example is that the file parser can detect
> inconsistencies _immediately_, while in the Modelica the checks are
> "delayed" until the parser reaches the "equation" section. This is not
> a problem for small scale files, but it is for large scale models,
> where the human cannot oversee the complexity anymore. Or when models
> are changed/adapted at runtime (which is inevitable in complex
> interactions). That means that a valid Modelica description can make
> you loose lots of time, for the same reason as a non-allocated memory
> pointer causes problems in large-scale C-programs...
> Of course, the Factory cannot guarantee that what it constructs
> corresponds to what the programmer _thought_ he was modelling, but
> lots of errors could be caught this way.

I don't really understand what specific benefit you see in this.  For example, even if you made the connect statements syntactically close to the declarations, it still doesn't say at what point the semantic processing will check anything.  Furthermore, it isn't clear to me what it would detect?  You just want to check that the model was connected to something?  You can do that without requiring that they be syntactically close to each other.  Are you worried about the amount of time it would take to process the declarations (and therefore the time it will take to get to the equation section)?  I really don't see that as an issue.  Even for large models, the complexity is nested in hierarchies so the declaration section isn't usually very long.  Or, are you talking about the time wasted trying to figure out what isn't connected that should be?  That can also be dealt with in the language
  by making an assertion in the model requiring that a port be connected.  That is support!
 ed by the language.

> > 1 - Annotations are not used strictly for graphical representation.
> 
> The more uses you find for the annotations the worse they become!
> Haven't we learned enough times that a standard that has a
> construction with which the user of the standard can do what he likes
> is not a standard anymore! Suppose Dymola would use the annotations
> to decribe geometry in a proprietary format; that means that it would
> lock its users into its own software, because other Modelica
> compatible software could _parse_ the file but not _use_ it in the
> same way as Dymola...

I didn't make this point explicitly, but annotations are used for things that DO NOT affect the behavior of the model.  As such, it should always be safe to ignore them and still be able to simulate a model.

> Herman