Feature: Make intentions customizable through an extension point

[alexanderpann]

• The extension point is called IntentionCustomization.
• Fixes Disable intentions of ISolvable #1378 in 2025.1 where you can now disable those intentions.

Example usage:

extension CustomizeEvaluateTestItem of IntentionCustomization { 
   
  activate 
  deactivate 
   
  IIntentionCustomizations get() { 
    new IIntentionCustomizations() { 
      *package* DefaultIntentionCustomization defaultCustomization = new DefaultIntentionCustomization(); 
      /** 
        Returns the priority of the current configuration. The configuration with the highest priority will be chosen. 
       */ 
      @Override 
      public int getPriorityLevel()  { 
        0; 
      } 
       
      @Override 
      public IntentionCustomization getCustomization(node-ptr<BaseIntentionDeclaration> node)  { 
        if (node :eq: node-ptr/EvaluateTestItem/) { 
          return new IntentionCustomization() { 
            @Override 
            public boolean isApplicable(node<> node, EditorContext editorContext, { => boolean} originalImpl)  { 
              originalImpl(); 
            } 
            @Override 
            public string getDescription(node<> node, EditorContext editorContext, { => string} originalImpl)  { 
              "Evaluate It"; 
            } 
          }; 
        } 
         
        defaultCustomization.getCustomization(node); 
      } 
    }; 
  } 
}

[kbirken]

TBH, I do not see the need for this big cross-cutting change. Is there a ticket with a real motivation why this is necessary?

The mentioned ticket #1378 is just a request to disable a handful of intentions, and I am sure this could be done by setting some property programmatically, or implementing some local/specific logic (similar to a feature flag) in the intentions which should be disabled.

The changes in this PR affect all intentions in the repository. There is a lot of boilerplate code in every intention, and the maintainability is poor. Moreover, how could it be ensured that new intentions will boilerplated same as the old ones?

@alexanderpann @AtanasM98 Pls. comment.

[alexanderpann]

The mentioned ticket was just an additional ticket that was fixed as a result. The idea is to make KernelF more customizable through customizing of the editor (#1522), customizing intentions (this PR, e.g. translating descriptions to a different language or disabling intentions) and customizing aliases (MPS-Extensions, again translating/changing terms). Those requirements come up every so often in customer projects. We are talking about 3 lines of code per intention. I'll have a discussion about the aliases with @wsafonov and @sergej-koscejev anyway. If people are unhappy with the changes after dicussion, I revert them.

[kbirken]

Thanks for your offer to revert the PR, I would highly appreciate that.

The mentioned ticket was just an additional ticket that was fixed as a result.

I would not close the ticket #1378 as of now, as long as the discussion is ongoing. As the requester uses MPS 2022.x, the changes in mps20251 won't help anyway. I sketched an approach in that ticket, maybe this is feasible (and without changes to IETS3 at all).

The idea is to make KernelF more customizable through customizing of the editor (#1522), customizing intentions (this PR, e.g. translating descriptions to a different language or disabling intentions) and customizing aliases (MPS-Extensions, again translating/changing terms). Those requirements come up every so often in customer projects.

Customers may talk about such customizations, but I would strongly suggest to "translate" their wishes into sustainable tickets in the specific platform every time. This process of writing a platform ticket capturing and generalizing the customer's requests is sometimes tedious, but nevertheless necessary to document the requirements (at least the motivation) and how the platform design is planned to be changed to reflect this.

In some cases it is also okay to implement something without direct customer requirements (e.g. infrastructure changes, prototypical new features, ...). But here IMO it is again good practice to create tickets describing the motivation of the change (except for very technical changes like cascading merges and dependency updates).

We are talking about 3 lines of code per intention.

Actually, for each of about 250 intentions four concept functions have been wrapped with boilerplate code, and where the concept function was not needed before, a wrapped default implementation had to be added (as is often the case for "child filter"). My point is: We are using the MPS generative approach and DSLs to avoid boilerplate code on any level, so it is quite counter-intuitive to spread >1000 lines of such code in our own platform.

If there is a requirement for this kind of customization, it should be defined crisply in a ticket, and we should then think hard to implement a solution which applies the generative approach so that minimal or (even better) no changes to the intentions code are necessary at all.

I'll have a discussion about the aliases with @wsafonov and @sergej-koscejev anyway. If people are unhappy with the changes after dicussion, I revert them.

I don't know the other two requests, but I am very much in favour of reverting this one.

[alexanderpann]

Customers may talk about such customizations, but I would strongly suggest to "translate" their wishes into sustainable tickets in the specific platform every time.

In this case, the idea for the ticket came from me. I will still create a ticket next time.

I recognized that I just made the chance at the wrong place. There is a solution in MPS-extensions that I overlooked (we are already customizing extensions there), that's why I came up with this approach. Still, you are right. Every time we have this repetitive code, it is a good indicator that there might be a better solution.