Add RFC: Native support for interface declarations

Update RFCNNNN-Native-Support-for-Interface-Declarations.md
PowerShell · IISResetMe · IISResetMe · IISResetMe · Nov 21, 2018 · felixfbecker
diff --git a/1-Draft/RFCNNNN-Native-Support-for-Interface-Declarations.md b/1-Draft/RFCNNNN-Native-Support-for-Interface-Declarations.md
+
+# interface declaration with a method
+interface IMyInterfaceWithMethod {
+    [void] DoSomething([int]$IntParam)
diff --git a/1-Draft/RFCNNNN-Native-Support-for-Interface-Declarations.md b/1-Draft/RFCNNNN-Native-Support-for-Interface-Declarations.md
+
+```powershell
+# interface declaration with no members
+interface IMyInterface { }
diff --git a/1-Draft/RFCNNNN-Native-Support-for-Interface-Declarations.md b/1-Draft/RFCNNNN-Native-Support-for-Interface-Declarations.md
+}
+```
+
+*Note: [C# 8 is slated to support default implementations](https://blogs.msdn.microsoft.com/dotnet/2018/11/12/building-c-8-0/) for interface methods, something we might want to consider as well*
diff --git a/1-Draft/RFCNNNN-Native-Support-for-Interface-Declarations.md b/1-Draft/RFCNNNN-Native-Support-for-Interface-Declarations.md
+
+Currently, when the parser recognizes a `class` or `enum` declaration, it produces a `TypeDefinitionAst` made up of `PropertyMemberAst` and `FunctionMemberAst` children. The type definition AST is then dispatched to either TypeDefiner.DefineTypeHelper or TypeDefiner.DefineEnumHelper for creating and emitting the corresponding runtime type.
+
+We can either add new `AbstractMemberAst` types specifically for the purpose of abstract type definitions, or modify the existing `MemberAst` types to account for abstract member constraints.
diff --git a/1-Draft/RFCNNNN-Native-Support-for-Interface-Declarations.md b/1-Draft/RFCNNNN-Native-Support-for-Interface-Declarations.md
+
+Going with separate AST types for abstract type members would reduce the number of branches and special cases required in the rest of the code base, but the obvious benefit of reusing existing AST types for member declarations is that we can do not have to extend the existing AST visitor surface (ie. no `IAstVisitor3 : IAstVisitor2`, `AstVisitor3 : AstVisitor2, IAstVisitor3` etc.). This may present hidden parsing issues for tooling developers though.
+
+Regardless of design changes to the AST surface, we can either define a new `TypeDefiner.DefineInterfaceHelper` for emitting interface types, or we can modify the existing `DefineTypeHelper` definition to take the `Interface` attribute into account and modify all the other emitting functions being called by it.
diff --git a/1-Draft/RFCNNNN-Native-Support-for-Interface-Declarations.md b/1-Draft/RFCNNNN-Native-Support-for-Interface-Declarations.md
+There are a couple of open questions around the design and implementation of interface declaration support:
+
+ - Should we allow control over getter/setter declarations?
+   - If so, should we replicate the syntax from C#?
diff --git a/1-Draft/RFCNNNN-Native-Support-for-Interface-Declarations.md b/1-Draft/RFCNNNN-Native-Support-for-Interface-Declarations.md
+ - Should we allow control over getter/setter declarations?
+   - If so, should we replicate the syntax from C#?
+ - Existing class definitions need to [mark interface member implementations virtual](https://github.com/PowerShell/PowerShell/issues/8302)
+ - Depending on community feedback and envisioned use cases, are interfaces sufficient or might we consider `abstract` classes as well? 
diff --git a/1-Draft/RFCNNNN-Native-Support-for-Interface-Declarations.md b/1-Draft/RFCNNNN-Native-Support-for-Interface-Declarations.md
+## Motivation
+
+    As a module author,
+    I can leverage common OO design patterns that require abstract type definitions,
diff --git a/1-Draft/RFCNNNN-Native-Support-for-Interface-Declarations.md b/1-Draft/RFCNNNN-Native-Support-for-Interface-Declarations.md
+
+# Native Support for .NET Interface Declarations
+
+The PowerShell Classes feature introduced in PowerShell 5.0 allows for type definitions at runtime. Since open sourcing PowerShell Core, one of the most oft-repeated feature request I've heard from community members is the ability to also declare and define interfaces at runtime, usually for ease of implementing common software design pattern such as the Builder pattern.

		Currently, when the parser recognizes a `class` or `enum` declaration, it produces a `TypeDefinitionAst` made up of `PropertyMemberAst` and `FunctionMemberAst` children. The type definition AST is then dispatched to either TypeDefiner.DefineTypeHelper or TypeDefiner.DefineEnumHelper for creating and emitting the corresponding runtime type.

		We can either add new `AbstractMemberAst` types specifically for the purpose of abstract type definitions, or modify the existing `MemberAst` types to account for abstract member constraints.

		Going with separate AST types for abstract type members would reduce the number of branches and special cases required in the rest of the code base, but the obvious benefit of reusing existing AST types for member declarations is that we can do not have to extend the existing AST visitor surface (ie. no `IAstVisitor3 : IAstVisitor2`, `AstVisitor3 : AstVisitor2, IAstVisitor3` etc.). This may present hidden parsing issues for tooling developers though.

		Regardless of design changes to the AST surface, we can either define a new `TypeDefiner.DefineInterfaceHelper` for emitting interface types, or we can modify the existing `DefineTypeHelper` definition to take the `Interface` attribute into account and modify all the other emitting functions being called by it.

		# Native Support for .NET Interface Declarations

		The PowerShell Classes feature introduced in PowerShell 5.0 allows for type definitions at runtime. Since open sourcing PowerShell Core, one of the most oft-repeated feature request I've heard from community members is the ability to also declare and define interfaces at runtime, usually for ease of implementing common software design pattern such as the Builder pattern.