This project is read-only.

Remove internal abstract methods from SyntaxNode


I have class hierarchies of my own classes that uses generic type parameters constrained to SyntaxNode.

These need to follow a very clear type parameter pattern because they are retrieved from an IoC and organized based on their type parameters.

I have a few classes that need to follow this pattern that do not relate to a SyntaxNode type (they work with parts of the trivia of other syntax nodes).

I would like to have an NoSyntaxNode class and cannot build one myself because of issues deriving from SyntaxNode.

My preferred fix is that we be able to derive from SyntaxNode. I would create a NoSyntaxNode and no one else would worry about this weirdness. The problem lies in these methods:
    internal override AbstractSyntaxNavigator Navigator { }
    internal override SyntaxNode GetCachedSlot(int index)
    internal override SyntaxNode GetNodeSlot(int slot)

My workaround is to use SyntaxNode itself. In my context, this is a statement that all syntax nodes will work, rather than no syntax nodes working, and this requires a lot of extra hits to a "CanCreate" method. It is also an incorrect statement about the intent of the class. I can't create a special case for SyntaxNode because there are other classes that do actually work for all SyntaxNodes as a fallback.

Possible Fixes:

1) Because other people interested in deriving from SyntaxNode may have different goals where the syntax node can't be non-functional, the best fix would allow programmers to derive from these and make them work. I don't really care how the offending abstract members disappear - expose as protected internal or supply a dummy implementation.

2) Provide an interface on SyntaxNode that is "ISyntaxNode" The problem I see with this is that interfaces are so brittle and it's either an empty interface or contains the current public methods on SyntaxNode and be a tad brittle

3) Another alternative solution is for you to add a "NoSyntaxNode", but I'm not sure there are any other scenarios for it, other than type parameter constraints. But I think the hierarchy pattern I'm using is likely to be useful to other people writing code against syntax trees as well and the impact for adding this seems pretty low.

For the scenario: I'm rewriting the part of RoslynDom so you probably want to avoid getting lost in the maze of factory access. Although the factories themselves that show this pattern are pretty solid, except for a badly needed cleanup. You can see the class hierarchy in classes like RDomClassFactory in the CSharpFactories/Factories at I'll post when I update the access so you can better follow how I am using the TSyntax type parameter.