How can I restrict the scoping of extended concepts? Follow

I dont understand exactly what you are trying to do.

But here are some things you can try:
Just add a non-type-system rule. This will create a error/warning, when something wrong is entered.

To restrict the scoping (the suggestions) is a bit harder.
I just tried the following:
I created a concept Interface2 that extends Interface.
I created a concept MethodDecl2 that extends MethodDeclaration.

I added a child to Interface2 with Type MethodDecl2 and specializes(overrides) "method".

The I added a child to MethodDecl2 with StringType as returnType that specializes "returnType".

So I could reduce the suggested and valid return-types in that Interface to just the StringType.

(Without using constraints or non-type-system rules.)

Thanks for the fast answer.
The second procedure is close to my requirements. But is it posible to check certain conditions instead of only restrict the type? I try to implement a custom visibility scope comparable to the one used in the Classifier Concept. But implementing a default scope for my extendet interface doesn't work.

second thing:
I've noticed a strage behavior when specializing the inherited "method". For the case of choosing InstanceMethodDeclaration as the type I expect no change in the behavior. But in this case I can't iterate over the InstanceMethodDeclarations any longer. Seems like the cardinality of method changed to one. It also can't be used in the editor aspect any longer.

Any suggestions?

Of course can you restrict the scoping, too.
You just need to find the concept that has the reference you want to change the scope for. Then make a subclass from that and reduce the scope. Then use that subclass in the matter shown above.


What do you mean by iterate? Did you give it a new name or the same name? Did you change the cardinality?

Thanks for the tipp, I'll try it :-)

I gave it the same name "method". The cardinality is not editable when you specializing a role.
When I inherit from Interface I can use collection methods like "select", "select many", etc. When I specialize "method", these functions aren't visible.

I've tested your suggestion. I've subclassed the ClassifierType and choose the new subclass as specialization. As a result the subtypesOfClassifierTypeWWildcards TypeSystemRule of the ClassifierType fail and return the error that the refered class is not a subclass of itself.
I get the following exception:



Any ideas?

Sorry, no ideas.

Can you provide detailed information, what your metamodel looks like. What do you want to do, and what concepts have you created? Which concept extends what etc.

The goal is to restrict the scope for ClassifierTypes of a custom class based on baseLanguages ClassConcept. I don't want every ClassifierType in the suggestions but only types that matches a certain condition. So I've subclassed the FieldDeclaration concept with a custom one and specialized the fieldDeclaration role in my custom classConcept. In the FieldDeclaration I've specialized the type role to a custom subclass of ClassifierType. For the custom ClassifierType I specialized the role classifier to my custom ClassConcept to allow only FieldDeclarations with the type of my custom class concept. The scoping (suggestion menu) looks now like expected, but when creating a node the error of my last post appear. For the case of specializing the classifier role of my custom ClassifierType to Classifier (don't change the type) the creation of the node works like expected, but when using the declared field (calling a declared method of the custom ClassConcept) I get the error that the type of my class (the one used for the field declaration) is not a subtype of itself.
Very strange behavior...

I think you should not inherit from ClassifierType but from Type.

ClassifierType is a really complex thing, especially because of Java-Generics.


Does it make sense?

In Type you don't have a classifier role wich I want to restrict. In the case of using Type I have to rewrite a ClassifierType without parameters. That's a really complex thing, too. The Type I need is a ClassifierType with restrictions...

I think I've solved the Problem... I've subclassed the ClassifierType and added a subtyping typesystem rule returning a new ClassifierType with the current classifier of my ClassifierTyp subclass.
To restrict the scope, I've added a reference constraint for the classifier role and return only the nodes matching my condition