SymTypeExpression and wrappers return a supplier in case the symbol c… by SE-FDr · Pull Request #372 · MontiCore/monticore

SE-FDr · 2026-09-07T09:00:40Z

…an not be resolved immediatly

SE-FDr · 2026-09-07T09:10:31Z

+    ASTCDAttribute attribute = ast;
+    String templateName = "methods.Set";
+    if (getDecorationHelper().isSupplier(ast.getMCType())) {
+      // expose the unwrapped type (Supplier<X> -> X) in the setter parameter; the Supplier stays hidden


This may need another method:
one that allows one to set a supplier (for Lazy creation in, e.g., SymbolAdapters).

SE-FDr · 2026-09-07T09:12:07Z

+  };
+
+
+  public static boolean shouldBeSupplied(String t) {


shouldBeSupplied -> shouldHaveSupplier/shouldBeAccessedViaSupplier/etc.

SE-FDr · 2026-09-07T09:12:22Z

+import java.util.Arrays;
+
+
+public class AccessAsSupplierTyps {


Suggested change

public class AccessAsSupplierTyps {

public class AccessAsSupplierTypes {

SE-FDr · 2026-09-07T09:12:50Z

+import java.util.Arrays;
+
+
+public class AccessAsSupplierTyps {


needs documentation on what this class is for

SE-FDr · 2026-09-07T09:13:30Z

+
+public class AccessAsSupplierTyps {
+
+  public static final String SUPPLIER_TYPE = "java.util.function.Supplier";


does this need to be public?

SE-FDr · 2026-09-07T09:18:43Z

+      return;
    }
+
+    String defaultValue;


the defaultValue is what comes after the =.
This is more like the defaultInitialization or simmilar?

SE-FDr · 2026-09-07T09:21:24Z

+    return ((ASTMCGenericType) type).getMCTypeArgumentList().get(0);
+  }
+
+  public ASTMCTypeArgument getReferenceTypeFromSupply(ASTMCType type) {


Suggested change

public ASTMCTypeArgument getReferenceTypeFromSupply(ASTMCType type) {

public ASTMCTypeArgument getReferenceTypeOfSupplier(ASTMCType type) {

?

SE-FDr · 2026-09-07T09:22:16Z

+    return ((ASTMCGenericType) type).getMCTypeArgumentList().get(0);
+  }
+
+  public ASTMCType createSupplierTypeOf(ASTMCType inner) {


Would this fit more in the MCTypeFacade?

SE-FDr · 2026-09-07T09:24:36Z

@@ -21,11 +21,11 @@ public void setFunctionList(List<FunctionSymbol> methodList){
  }

  public List<SymTypeExpression> getSuperClassesOnly(){
-    return superTypes;
+    return superTypes.get();


prefer something like getSuperTypesList()

Why do both methods return the same? Is this correct?

... yes, kind-of.
It is questionable design wise,
but the idea is that we cannot distinguish between them for TypeSymbols,
so we simply return them all.

SE-FDr · 2026-09-07T09:24:47Z

  }

  public List<SymTypeExpression> getInterfaceList(){
-    return superTypes;
+    return superTypes.get();


here as well

This reverts commit bd04066.

…an not be resolved immediatly

This reverts commit bd04066.

SymTypeExpressoions are wrappen in supplier for deser add getRa/ set raw removed unneccessary DeSers replaced errors with info for compatibility

scopes can use supplier removed wrong desers

from internal to normal supplier wrapping all shouldBeWrapped attributes avoiding double-wrapping internal supplier deep-clone now works with suppliers

SE-FDr · 2026-09-22T07:29:13Z

+  public static <T, R> Supplier<R> map(Supplier<T> source, Function<? super T, ? extends R> mapper) {
+    return new ClearingMemorizer<>(() -> {
+      T value = source.get();
+      return value == null ? null : mapper.apply(value);


why can the mapper not accept null?

SE-FDr · 2026-09-22T07:29:15Z

+ * Evaluates the wrapped supplier at most once and caches the result. Afterwards the
+ * supplier is released (and with it everything it captured, e.g. the JSON it deserializes from).
+ */
+public class ClearingMemorizer<T> implements Supplier<T> {


Why is it called Clearing? that is an internal detail.

SE-FDr · 2026-09-22T07:33:22Z

+  /**
+   * Wraps the type of every attribute that {@link #shouldHaveSupplier} selects into the internal supplier type.
+   */
+  public void wrapSuppliers(Collection<ASTCDAttribute> attributes) {


wrapSuppliers does not say anything about storing the values

SE-FDr · 2026-09-22T07:35:26Z

+   * so the internal wrapper never leaks into the public API.
+   */
+  public ASTMCType toPublicSupplierType(ASTMCType type) {
+    return createStdSupplierTypeOf(unwrapSupplier(type));


This makes me wonder if the setup is too complex.
I am not sure.

…on because we have multiple return types) made ClearingMemorizer.map more general

SE-FDr · 2026-09-22T07:38:52Z

  }

+
+  public static TypeSymbol resolveTypeSymbolOrLogError(


This should not be part of its public api, it has nothing to do with the Factory directly

SE-FDr · 2026-09-22T12:52:11Z

@@ -21,11 +21,11 @@ public void setFunctionList(List<FunctionSymbol> methodList){
  }

  public List<SymTypeExpression> getSuperClassesOnly(){
-    return superTypes;
+    return superTypes.get();


... yes, kind-of.
It is questionable design wise,
but the idea is that we cannot distinguish between them for TypeSymbols,
so we simply return them all.

…and no residuals in the final generated code

SymTypeExpression and wrappers return a supplier in case the symbol c…

741ad34

…an not be resolved immediatly

SE-FDr commented Sep 7, 2026

View reviewed changes

Chrisslue and others added 17 commits September 10, 2026 09:53

PR feedback

d590008

use __internal__Supplier

3982a02

supplierGet now warn instead if throwing

8526745

spike through SymTypeOfObject now uses supplier

bd04066

Revert "spike through SymTypeOfObject now uses supplier"

91f492d

This reverts commit bd04066.

SymTypeExpression and wrappers return a supplier in case the symbol c…

437fe93

…an not be resolved immediatly

PR feedback

8f29bd2

use __internal__Supplier

6aa41fa

supplierGet now warn instead if throwing

48fee8d

rebase

20bed4b

Revert "spike through SymTypeOfObject now uses supplier"

2e7007e

This reverts commit bd04066.

Merge remote-tracking branch 'origin/add-supplier' into add-supplier

b97dc96

broken

09cb397

SymTypeExpressoions are wrappen in supplier for deser add getRa/ set raw removed unneccessary DeSers replaced errors with info for compatibility

Builder can use supplier

58c28a6

scopes can use supplier removed wrong desers

removed suppliers from SymTypeExpression desers

3b7a68d

Merge upstream/dev into add-supplier

c7d3848

extracted duplicate code:

e02cd6d

from internal to normal supplier wrapping all shouldBeWrapped attributes avoiding double-wrapping internal supplier deep-clone now works with suppliers

SE-FDr commented Sep 22, 2026

View reviewed changes

Chrisslue added 2 commits September 22, 2026 12:31

make all the decorator look the same (don't want to pull out a functi…

22c7377

…on because we have multiple return types) made ClearingMemorizer.map more general

tests for new decorations

0993d94

SE-FDr commented Sep 22, 2026

View reviewed changes

Chrisslue and others added 3 commits September 23, 2026 12:49

tests for new decorations

396e9b5

moved resolveOrLogError to out of factory

8ac98c6

reduce __internal__supplier to a pure marker, without implementation …

b81d69b

…and no residuals in the final generated code

	public class AccessAsSupplierTyps {
	public class AccessAsSupplierTypes {


		public class AccessAsSupplierTyps {

		public static final String SUPPLIER_TYPE = "java.util.function.Supplier";

	public ASTMCTypeArgument getReferenceTypeFromSupply(ASTMCType type) {
	public ASTMCTypeArgument getReferenceTypeOfSupplier(ASTMCType type) {

Conversation

SE-FDr commented Sep 7, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants