DSL should show when the implementation of a function is in code (ie Java)

[Oblongs]

Some functions are implemented using helper code behind the scenes, using Java. These implementations override everything that exists in the function definition in the DSL.

There should be a way of making this visible in the DSL definition such that:

• the reader of the function knows that there is a hidden implementation
• any code added to the function creates a syntax error (to prevent accidental addition of code that will be ignored)
• an implementation cannot override the function without the designation in the function.

This could be annotation in the function, eg:

func codeImplementation:
   inputs:   foo Bar (1..1)
   outputs:  boo Far (1..1)

   [codeImplementation]

[dschwartznyc]

rather than focusing on whether the implementation is in Java specifically, could the DSL note when a function defines an interface with no implementation? generators could then take that as a signal for native implementation or to manage the lack of one (throw an exception?)

[SimonCockx]

This would be useful to have. Agreed on all parts , except:

an implementation cannot override the function without the designation in the function.

I think this is not desirable. Overriding existing implementations in Java is sometimes needed in (client-specific) extensions of the CDM/DRR model. We want to keep this possibility. However, I do agree that this should be exceptional, and that in the usual case only Rune functions that do not have a Rune implementation should be overridden.

Couple of other syntax ideas:

func MyFunc:
  [codeImplementation]
  inputs:   foo Bar (1..1)
  outputs:  boo Far (1..1)

abstract func MyFunc:
  inputs:   foo Bar (1..1)
  outputs:  boo Far (1..1)

func MyFunc:
  [abstract]
  inputs:   foo Bar (1..1)
  outputs:  boo Far (1..1)

[dschwartznyc]

seems like an abstract designation would be helpful especially since it would allow the generators to distinguish between an empty and a not implemented function