Ref.cell code completion strange behaviour

Hello to MPS team

I'd encountered a strange bug (or feature, demo version limitation, something else - I don't know). When ref.cell-caused code completion invoked, I can't see actual properties in displayed list. This list consists of equal elements with concept names displayed.

In the demo sample attached (please, don't joke about it's utility:) ) this behaviour looks much expressive.

Does any workaround existed for the current build#262? Or, may be, this behaviour caused by my crooked hands?



Attachment(s):
constraint_editor.PNG
constraint_code_completion.PNG
9 comments
Comment actions Permalink

hi ,

this may happen because either table (instance) has no name or the table concept doesn't extend the NamedConcept.

Igor.

0
Comment actions Permalink

Thanks a lot!

My MPS understanding becomes more and more clear:)

But (if not secret) what's the reason for such a difference? In other words, why we need to manually distinguish between BaseConcept and NamedConcept? I think, it is possible to assume on generation stage if there is an editor containing ref.cell for node X and to generate class with appropriate superclass, don't it? Or may be, the reason is "to keep things clear" at the early development stage?

0
Comment actions Permalink
      • strictly confidential ***

I think such an inference is hardly possible and not necessary.

A property with name 'name' is just regular string unless the declaring concept inherits from the NamedConcept.

In the former case the 'name' property is charged semantically.

It is your developer choice what do you need.

To me there is considerable difference between named and unnamed concepts because named element can be addressed by its unique name (in scope) and unnamed - cannot.

That fact has many practical consequence concerning searching, caching, mapping, presentation etc.

igor.

1
Comment actions Permalink

I think it's probably good design choice except the case when we need to use parts of existing DSL in a new one. If we marked imported DSL concept as BaseConcept, we have no ability to "override" it's behaviour (without valuable changes in "base" DSL) and thus we restricted not to use the concept as a reference with a ref.cell front-end.

Yes, there is a conceptual workaround (based on "Replace inheritance with delegation" pattern) existed. It's possible to create "wrapper" concept that inherits NamedConcept and references an old one. But can we associate it's "name" property with any property of referenced concept?

0
Comment actions Permalink

Currently it's not possible to make a property value computable. But, we now know how to mix declarations and computations.

It's already done for 'key maps' in editor  ( mixture: editorLang + ) and for cell's 'rendering condition' (not in build yet).

Perhaps, we will need to design another one 'bootstrap' language - constraintsLanguage - providing ability to put various constraints on concept, relations and properties.

0
Comment actions Permalink

I was impressed by SModelLanguage features presented in current build & had already privately discussed about strong neccesity of such a language for (Node | RHintTransform)SubstituteActions with Konstantin Solomatin.

Constraints bootstrap language can be very helpful too, especially for concept relations like references, because it can deliver anyone from "hardcoding" action filters, for example.

P.S. - Thanks again for great support!:)

0
Comment actions Permalink

Offtopic : My Last name is Solomatov not Solomatin :-)

0
Comment actions Permalink

Ooops! Sorry! A thousand apologies :-)

0
Comment actions Permalink

Thats ok :-)

0

Please sign in to leave a comment.