Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Projection declaration redesign(Symbol, explicit params and typing) #1131

Open
timotheeguerin opened this issue Oct 5, 2022 · 1 comment
Labels
design:needed A design request has been raised that needs a proposal
Milestone

Comments

@timotheeguerin
Copy link
Member

timotheeguerin commented Oct 5, 2022

Updated proposal taken from #928

Update to projection declaration

Separated in 3 steps that could be implemented one by one.

1. Projection name as symbol

Changes:

  • Make the projection name a symbol. This will resolve the issue with calling conflicting projections.
    • projection keyword is used to declare the projection name
    • project keyword is used to declare a projection implementation

Effect:

  • Projection name is an actual reference, reduce typo and conflicts chances
projection target;

project model#target {
  to(targetName) { ... }
  from(targetName) { ... }
}

// Use projection name fully qualified name
project namespace#Foo.target {
  to(targetName) { ... }
  from(targetName) { ... }
}

Usage of projection

runProjection(program, [
{
  projection: "Cadl.target" // use the fully qualified name
  arguments: ["json"]
}, 
{
  projection: program.resolveReference("Cadl.target"), // Or resolve the projection reference manually.
  arguments: ["json"]
}, 
]

2. Define arguments on the projection declaration

Change

  • The projection declaration define the list of arguments that are expected.
  • Move the argument list to the project declaration

Effect:

  • This makes it that to and from MUST have the same arguments.
projection target(targetName);

project model#target(targetName)  {
  to{ ... }
  from { ... }
}

// Could name the parameter differently.
project interface#target(targetId)  {
  to{ ... }
  from { ... }
}

3. Add typing to arguments

Changes:

  • Projection declaration can define the types.
    • Could type be optional?
  • Projection implementation has to redefine the parameter(s) but the type can be inferred
    • If type is specified explicitly it MUST match exactly the one on the projection declaration.

Effect:

  • Running a projection will emit diagnostic if passing invalid arguments.
projection target(targetName: StringLiteral);

project model#target(targetName)  {
  to{ ... }
  from { ... }
}

// Can be explicit with the type
project interface#target(targetName: StringLiteral)  {
  to{ ... }
  from { ... }
}

@timotheeguerin timotheeguerin added the design:needed A design request has been raised that needs a proposal label Oct 5, 2022
@ghost ghost added the Needs Triage label Oct 5, 2022
@markcowl markcowl added this to the [2022] November milestone Oct 10, 2022
@timotheeguerin
Copy link
Member Author

Alternative proposal discussed

namespace Cadl;

projection target(targetName) {
  model {   ^ identifier
    to { }
    from { }
  } 
  
  interface {
    to {}
    from {}
  }  
}

// another lib
use projection Cadl.target(targetName) {
  MyModel {     ^ reference 
   to {} from {}
  }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design:needed A design request has been raised that needs a proposal
Projects
None yet
Development

No branches or pull requests

3 participants