0

MPS 3.0 replacement for a concept property

fabma

October 31, 2013 17:16

None

During the migration to MPS 3 all concept properties have been replaced by static behavior methods. This is fine in many cases but not in all. If you want to save a state at runtime inside the property you can't do this just with a method.
In my case I have used the property to save the decision if a property is displayed with a keyword or with an icon. With an action or intention the user could switch between the representations and this has effected all nodes with this property. I don't know how to implement this behavior again in MPS 3.0? Has anybody an idea?

• Facebook
• Twitter
• LinkedIn
• Google+

3 comments

• 0
  
  Askar Kalykov November 01, 2013 02:40

  Hi fabma. Do you tried to use utility model with public static class field? As I understood, this would fit your needs well.
• 0
  
  fabma November 01, 2013 08:32

  Hey Askar! Thanks for this suggestion. I haven't seen this very simple solution but I think it is some kind of dirty hack since in MPS 2 it was possible to store this information directly inside the node model.
  But for now I have had a closer look to the editor hints. They are a bit more complicated to use, because they can't be accessed from a editor component, but are probably the right tool for my problem.
• 0
  
  Mihail Muhin November 05, 2013 01:15

  I would say in your case these were not concept properties, but rather some "editor settings", which are better to be stored not in a model. You can use (e.g.) PersistentComponents from plugin language to save those settings. The problem arises when your language is packaged, and the user can't make changes to its concepts - it will be impossible to change the view in this case.
  
  Anyway, we are now trying to make MPS simpler to understand and we've found that concept properties were a big misunderstanding at least in MPS codebase, used for 3 purposes actually.
  1) alias, description, canBeRoot and so on are not a "concept property", but just a property of the ConceptDeclaration instances, so that's how we changed it
  2) sometimes they are used to created "virtual" properties, e.g. ConceptFunction has a result concept property which is set in every instance. This seems to be closer to simple concept behavior methods, so now this kind is expressed with concept behavior
  3) they are also used to add a new feature to a concept w/o changing ConceptDeclaration - this can be expressed with just an annotation to that concept
  
  So, to have less ways to do the same thing and to have concept declaration simplified, we decided to remove concept properties.  
  
  Regards,
  Mihail