[SOLVED] Influence scoping on leftExpression/rightExpression for a concept that extendes BinaryOperation

Hi,

I face a similar problem as stated in [1] - I try to limit the scope of children of one of my concepts. I could reproduce the solution provided in [1], however my usecase is slightly different (I will state the issue with names according to the reference):

 

'Ports' and 'PortRefernces' are Expressions, 'Instance' extends the BinaryOperation concept and instead of a child for 'Ports', I want to reference only two 'Port's: one in the inherited child 'leftExpression' and one in 'rightExpression'. Unfortunately, the fix via the ScopeProvider does not work for this.

 

So my question is: How can I limit the expressions that are shown for 'leftExpression' and 'rightExpression' so that only 'Port's which have been defined in the according 'Component' are available?

 

Thanks!

N.

 

[1] https://mps-support.jetbrains.com/hc/en-us/community/posts/206613955-Simple-Constrains-problem-

 

edit: solved! used the solution provided in the official comment. thanks for the help!

0
4 comments
Avatar
Permanently deleted user
Official comment

Dear Norm,

I checked out your language.

Inner.can_be_used is very much like the visibility of static fields in baseLanguage.

So I suggest you to limit the possible references in completion via reference scope of InnerReference target.

I attach the screenshot with the code of InnerReference constraints aspect which should solve your problem.

In that code we firstly create the scope of  all instances of Inner concept within model and all imported models.

Then we filter this scope by node.can_be_used.

 

This scope influence on several things:

1) Prohibited targets will be excluded from the completion.

2) If a prohibited target node will be set somehow (e.g via console) as a reference,MPS will underline it as an error.




If i understood your question properly you you can acheive this by using Transformation Menu Language(https://confluence.jetbrains.com/display/MPSD34/Transformation+Menu+Language)  in MPS 3.4.

If you have further doubts we can discuss.

1
Avatar
Permanently deleted user

Sorry for the long answer delay - I did not manage to get to work on this lately.

I did some further experiments but it seems that your proposed way (using the transformation menu language) is not the best way to deal with this issue: I believe this modification is on the menu itself, rather on the scoping (which is where I expected this functionality to be done)? Which means that though certain nodes are not listed if a user copy/pastes them the DSL would accept it? Is that correct? If so - this is not the way I would like it to be.

To clarify: I would like to limit/filter the possible expressions (that are listed via ctrl+space) via the concept type and certain properties of these concepts. I consider this something to be done via scoping - is that correct?

Unfortunately I seem to be unable to restrict the scope of left/right expressions (which are node children) to this extend via constrains. How can I do this?

0
Avatar
Permanently deleted user

Hi,

I realised that I have the exact same issue as in question [0] and would love to know how to solve this. I created an example language at [1] to illustrate :

* I want to restrict the concepts available within my "MyBinaryRef" concepts leftExperession and rightExpression

* I managed to only allow my own concepts in there (see the constraint of MyBinaryRef)

* Further, I want to ONLY use 'Inner' concepts which have set the property 'can_be_used' to true (i.e. the "inner3" node should not be listed in the completion menu)

All my tries with the Transformation Menu Language did not work. Can someone explain which Transformation Menu has to be created for which concept for this to work? Any ideas?

Thanks in advance!

 

N.

 

[0] https://mps-support.jetbrains.com/hc/en-us/community/posts/205966644-Migration-from-Side-Transform-Actions-to-Transformation-Menu-Language

[1] https://github.com/nkoester/TrafoMenuTest

0

Please sign in to leave a comment.