Save function is misleading about ntypewriter HOT 3 OPEN

That behaviour was introduced here #75.

In general, it is a good idea to split Save into two functions: Save and AddSource, but as you already noticed #106 adding *.cs files as a source has some problems right now.

from ntypewriter.

I have created a fork in hope to get the requires changes done. But it seems a split is only possible with heavy refactoring or introducing new APIs / deprecating old ones.

My approach would be to deprecate certain APIs and introduce more flexible ones. I think the steps would be

• Define NTypewriter.Runtime.IGeneratedFile with properties Path and Content
• Make IGeneratedFileReaderWriter.Write(string, string) obsolete
• Add IGeneratedFileReaderWriter.Write(IGeneratedFile)
  • Allows GeneratedFileReaderWriter to cast for certain types implementing IGeneratedFile mentioned blow
• Add AddSourceFunction based on SaveFunction
  • Pass NTypewriter.SourceGenerator.GeneratedCSharpFile implementing IGeneratedFile to AddRenderedItem
• Implement IGeneratedFile in RenderedItem
• Add some logic in ``GeneratedFileReaderWriterfor handlingRenderedItem` and `GeneratedCSharpFile` differently

What do you think?

from ntypewriter.

I would prefer to add a flag AddToCompilation on NTypewriter.RenderedItem instead of using IGeneratedFile as a marking interface, anyway NTypewriter does not have a reference on NTypewriter.Runtime, so using interface there defined is not an option. Passing that flag through the whole execution path should be enough without introducing any new types.

from ntypewriter.