Community
Participate
Working Groups
The base protocol is currently part of the language specific runtime model library. This implies a couple of issues, e,g. whether the rtBound/rtUnbound within this base protocol should already be available when the language is not set. Other issues of the discussions in bug 498289 (from Peter Cigehn): (In reply to Charles Rivet from comment #26) > Unless, of course, the "No Language" option is provided with the same > capability as was is proposed for C++ to display these protocol messages, > but then you would have to explicitly ads this capability to every new > supported language... Yes, each supported target language will have its set of related libraries. And each such supported language will either be related to (the same) target language agnostic run-time model library (our current assumption), or possibly to its own target language specific run-time model library (as it is done in the legacy tooling). But since it just a reference to the same library I am not sure that this really is an issue. The intention with the default language framework is to make the addition of new target languages a simple configuration issue. So, we could very well relate the (current) target language agnostic run-time model library also to the "No Language". But on the other hand, I am not sure that is what we want either. For models that have no interest at all to the run-time model library, e.g. certain kinds of high level system models, I would prefer it those would not get the run-time model library to be loaded by default (see Bug 502547 for a related discussion to this). I would propose instead that we introduce another target agnostic language, which is *only* related to the run-time model library, but not to the AnsicCLibrary and the RtCppProperties profile. Related to this I also see Bug 502557 which aims to make it possible to select the default language already at the time you create the model. PS. Yet another dimension of this issue is also the fact that we choose to put rtBound/rtUnbound in the run-time model library itself. This was not really the only choice we had. If I compare with the legacy tooling, the rtBound/rtUnbound are kept in a completely separate library (actually not even modelled as protocol), not directly related to the run-time model library itself. If we absolutely want to have rtBound/rtUnbound available, disregarding if and which language has been selected, we could have chosen to place it in a library of its own. Not sure though if that really solves this issue though. DS.
[Copy of comment 30 from 498289, from Charles Rivet] (In reply to Peter Cigehn from comment #29) <...ship...> > Yes, each supported target language will have its set of related libraries. > And each such supported language will either be related to (the same) target > language agnostic run-time model library (our current assumption), or > possibly to its own target language specific run-time model library (as it > is done in the legacy tooling). The (or at least my) original view of the runtime model library was to include this, but in a different way, with the vision that actual, language-specific libraries could be created and used to generate the runtime. But we are very far from this becoming reality... <...snip...> > > I would propose instead that we introduce another target agnostic language, > which is *only* related to the run-time model library, but not to the > AnsicCLibrary and the RtCppProperties profile. I'm absolutely fine with this as a solution and I would propose it be the "Natural Language" language that is already listed as an option for opaque behaviors. <...snip...>
[Copy of comment 31 from 498289, from Charles Rivet] In reply to Charles Rivet from comment #30) > (In reply to Peter Cigehn from comment #29) <...snip...> > > I would propose instead that we introduce another target agnostic language, > > which is *only* related to the run-time model library, but not to the > > AnsicCLibrary and the RtCppProperties profile. > > I'm absolutely fine with this as a solution and I would propose it be the > "Natural Language" language that is already listed as an option for opaque > behaviors. > Note that this change can be made as part of v0.9.
[Copy of comment 32 from 498289, from Peter Cigehn] (In reply to Charles Rivet from comment #30) > (In reply to Peter Cigehn from comment #29) > > > > I would propose instead that we introduce another target agnostic language, > > which is *only* related to the run-time model library, but not to the > > AnsicCLibrary and the RtCppProperties profile. > > I'm absolutely fine with this as a solution and I would propose it be the > "Natural Language" language that is already listed as an option for opaque > behaviors. > Not sure if it "Natural Language" is the best fit for this case. I could very well see that certain kinds of high level system models would like to use "Natural Language" as their language assigned to the body of any opaque behaviors. And these models does not necessarily want to be related to the run-time model library. Keep in mind also that the default language framework will be tied into the creation of opaque behavior, opaque expressions and so on. The "default language" also refers to that the tooling shall ensure that all created opaque behavior, opaque expressions and so on, have the default language assigned to the body, e.g via the code snippet view. On the other hand, I do not have any better suggestion. Do "Natural language" in the list of proposed languages when creating opaque behaviors have any other "semantic" meaning in base Papyrus? Do it trigger the activation of some specific Xtext editor (which I assume happens when you have OCL as language for example)?
Moved to future until more information is received, enabling proper assignment.
