"Internal" APIs in MPS 2.0 M1

Hi,

my languages extend BaseLanguage and, thus, use a lot of APIs from MPS. Now, in version 2.0M1 some of these APIs became "internal", i.e., they are marked with "export(namespace = jetbrains.mps)", which means that my languages cannot call these functions anymore.

My question is: are you going to provide a standard API for the functionality that is now closed?

For example, how do I search nodes using the global scope if I can't use GlobalScope.getInstance()? This is needed when I search a model for nodes including imported...

Bests,

Thiago

11 comments
Comment actions Permalink

Hi Thiago,

Now list of Open API is not fully defined. The areas where we haven't finished with the Open API definition are still marked with "usage of nonpbulic API" in M1. I think the GlobalScope will be an open API, but it can be used only in UI aspects (e.g. plugin). Do not use it in constraints and behaviour aspects.

Mike.

0
Comment actions Permalink

Hi Mike,

thanks for the answer.

But then, if I shouldn't use GlobalScope, how can my semantic analysis (a constraint, for example) query for all elements of a certain type in the project, including import?

For example, I want to get all Classifiers that my project defines or uses. I was using the SModel.nodesIncludingImported(...) method, but it needs an IScope as parameter. Since IScope is closed, there's no way to use that method.

[]s

Thiago

0
Comment actions Permalink

Thiago,

Actually, GlobalScope class is a special case. It should not be used from MPS "core" (under this word I mean basic MPS aspects like Structure, Behavior, Constraints, Generator etc). I will try to explain this situation.

Consider a directed graph of module dependencies consisting of two components of connectivity with no connectivity between them in any way. Suppose you use GlobalScope in the first of them. It means that the first component automatically "knows" about the second one. But as the components are not connected, it must not.

So, you see, the only way to legally get another module (or model) from the current one is to get it in "by-dependencies" manner. In MPS, any node has a model, any model has a module (now some models can have more than one module, but we plan to change this - in 2.0 every model will have one owning module), and the module has dependencies on the other modules. This means that if you have any of them (node, model or module), you can theoretically get to nodes you may be interested in. Without using GlobalScope.

The GlobalScope class is very useful either when you write some UI - you may want to show _all_ models or modules, for example. Though, in my own opinion, we don't need a scope in this case at all.

Anyway, as Mike said, we don't know for now what should and what shouldn't be contained in open API. If something will be needed for the MPS users to write their features, we plan to provide either a language or open API for this. So, don't worry about these warnings now. I think we'll not make them "strict", it will be just a warning saying that this code can be changed and you'd better not rely on it, but try to migrate to DSL code or open API code.

Regards,

Mihail

0
Comment actions Permalink

Thiago,

The answer to your first question about "nodes including imported" is quite simple. In MPS, there's a DSL for some operations with SModel. Try the following:

private void myMethod(SModel sm){

  model m = sm;

  nlist roots = m.rootsIncludingImported<MyConcept>;

}

Here, we have the _model_ type, an it is compatible with SModel, but has a number of operations SModel does not. I suppose rootsIncludingImported is what you actually need.

BTW, I think SModel.nodesIncludingImported() does not actually need an IScope. I'm performing cleanup in SModel cleanup at the moment, so I'll look at this method tomorrow and maybe will remove this parameter.

Regards,

Mihail

0
Comment actions Permalink

Hi Mihail,

thanks for the detailed answers.

So, in my case, rootsIncludedImported is fine, because I am searching for Classifiers, which are roots. In general, though, one would like to have a simple way of searching any types of nodes, and that's nodesIncludedImported, I suppose.

However, I couldn't make it work yet. I tried in MPS 1.5 and 2.0_M1, and in both I cannot make the rootsIncludedImported<MyConcept> show up. I include the smodel language (as a "used language" of the model), but all I get are the roots/nodesIncludedImported methods which take a Scope as the first parameter.

Also, in MPS 2.0_M1 using GlobalScope raises an error, not a warning, which means I cannot compile. Is there a way to change the settings so that it's only a warning?

I liked your explanation about models, modules, etc. I really don't want to use GlobalScope. That was the only way I found to search for nodes of my model, including imported ones. I think that the API should have a simple way to query for this, without making me create a scope.

I am anxiously waiting for your cleanup ;-)

Cheers,

Thiago

0
Comment actions Permalink

Hi,

since we are in this subject, besides being able to search using the included models, it would be great to have an API to manipulate which models are included (essentially let us programmatically do whataver we can now do by going to "Model Properties" in the GUI).

For example, I would love to be able to add a new java stub import when I detect it is needed...

Bests,

Thiago

0
Comment actions Permalink

Hi!

Can you please file a request for it?

0
Comment actions Permalink

Thiago,

You can create one request for all the things you would like to see in openapi and just add all your issues to it as comments or to the description text.

Regards,

Mihail

0
Comment actions Permalink

Thanks.

BTW, I've taken a look at rootsIncludingImported operation in SModel language - it requires a scope parameter, which is not correct. So, now it seems that using GlobalScope is quite ok for your task.

I've created 2 bugs: about the operation and about "error" problem. Actually, now MPS generates and compiles models with "errors", so you can use this class.

http://youtrack.jetbrains.net/issue/MPS-10347

http://youtrack.jetbrains.net/issue/MPS-10349

Regards,

Mihail

0
Comment actions Permalink

Yeap, I realized later that I could compile even with errors.

Thanks for the new bug reports.

Bests,

Thiago

0

Please sign in to leave a comment.