Syntax ideas for supporting extension resources with lexical nesting

[brwilkinson]

Discussed in #1567

• moving to issue for visibility.
• related to:
  • Proposal - simplifying resource referencing (part 1) #2245
  • Proposal - simplifying resource referencing (part 2) #2246

^{Originally posted by anthony-c-martin February 17, 2021}

Syntax ideas for supporting extension resources with lexical nesting

This is an open discussion thread to come up with a syntax for declaring extension resources in a manner compatible with #1363. To get started, here are the options I see:

1. Try to infer it

a) Use the fact that the fully-qualified type must be supplied

resource myParent 'My.Rp/parent@2020-01-01' = {
  name: ...

  // this is an extension resource (type contains a single '/' character)
  resource myExtension 'My.OtherRp/extension@2020-01-01' = {
    name: ...
  }

  // this is a child resource (type does not contain any '/' characters)
  resource myChild 'child@2020-01-01' = {
    name: ...
  }
}

• Pros
  • Simple and ties in with the child resource declaration.
  • No special syntax required to declare an extension resource.
• Cons
  • Subtle, possible to introduce accidental bugs.
  • Doesn't map cleanly to the proposed 'parent' syntax for refactoring.
  • Intellisense for child resource types won't be as clean as it'll have to also show all possible extension resources.

b) Use a list of known extension types to understand whether or not the provided type string is an extension resource

Not considered - this removes the 'day 0 resource support' promise.

2. Some indicator of intent in the language or type string

a) Keyword

resource myParent 'My.Rp/parent@2020-01-01' = {
  name: ...

  // 'extension' keyword
  resource myExtension 'My.OtherRp/extension@2020-01-01' extension = {
    name: ...
  }
}

b) Prefix in the type string

resource myParent 'My.Rp/parent@2020-01-01' = {
  name: ...

  // prefix for the type string (option i)
  resource myExtension 'ext://My.OtherRp/extension@2020-01-01' = {
    name: ...
  }

  // prefix for the type string (option ii)
  resource myExtension '/My.OtherRp/extension@2020-01-01' = {
    name: ...
  }

  // option iii - some other prefix (not shown)
}

• Pros
  • Author's intent is clear and unambiguous.
  • Intellisense should be able to help with suggestions.
  • Clear mapping to/from the 'scope' property.
• Cons
  • Doesn't feel very natural, will probably require looking up the syntax each time.

Current state of the 'top-level' extension/child syntax (for reference)

resource myParent 'My.Rp/parent@2020-01-01' = {
  name: ...
}

// Extension resource
// NOTE - the type string for the resource being extended is not present in this declaration
// NOTE - there's also a potential proposal to rename 'scope' => 'extends'
resource myExtension 'My.OtherRp/extension@2020-01-01' = {
  name: ...
  // declare the resource that this one is extending
  scope: myParent
}

// Child resource
// NOTE - the type string is the fully-qualified type string instead of just 'child'. This is to permit intellisense before the 'parent' property has been entered.
resource myChild 'My.Rp/parent/child@2020-01-01' = {
  name: ...
  // declare the resource that this one is a child of
  parent: myParent
}

Notes

If picking option 1, it feels like it would make sense to come up with a consistent mapping between the 'top-level' syntax and the 'nested' syntax which combines both the 'parent' & 'scope' property into one.