haven1433/autoimplement

Provide automatic implementations for .net interfaces following boilerplate design patterns

autoimplement's Issues

update your readme

So, . . . now your using inline pattern matching which is a c#7 feature.

Desired Breaking Changes

This is a placeholder for things I'd like to improve in AutoImplement, but they'd be breaking changes. This means that the changes would have to wait for a major version bump.

• rename System.Delegation
  System.Delegation was chosen as a way to show that these are general types that have to do with using delegates for properties and events. However, the number of types that AutoImplement depends on has grown to include a custom equality comparer (for stub generic method implementations) and a constructor-delaying disposable (for class-stub delayed construction). Since none of these types need to be code-generated (they're the same in every case), it makes sense to store them in a helper assembly. But the current chosen name is misleading. A better name might be HavenSoft.AutoImplement.StubUtilities.
• less surprising method name overload resolution
  Stubs use properties to represent methods, to allow new implementations to be assigned on the fly. However, multiple methods can have the same name (compare Max(int,int) with Max(double,double)), while multiple properties cannot. This is currently handled by having the first method found receive a matching property, while any future methods get a property with a longer name that includes its input parameter types. Methods with out/ref parameters always get the longer name. This is confusing. Instead, if there is a single method, it should get the shorter name, and if their are multiple conflicting methods, they should ALL get the longer name. Alternatively, method conflicts could be solved via ImplementXYZ methods (similar to how generic methods are handled today). Either way, there should not be special treatment for the first method found, or for methods with out/ref parameters.
• Convert to .net core
  It's recently been announced that .net framework will not support C# 8. Development on .net framework is ramping down, and development on .net core is ramping up. AutoImplement should remain as a single version, ideally able to be used by any program. In order to support the maximal number of clients, compilation should move to .net core / .net standard.
• Move install directory to improve usability
  See #7

Formatting and functional bits of the generated code are tightly coupled in generator

The generator doesn't clearly differentiate between the formatting and functional bits of the generated code, which makes it hard to extend the generator to produce code in a different style and hurts the readability of the generator.

A few examples:

• StringWriter.Indent() describes a side effect of the IDisposable it creates, rather than the functionality. The brackets generated by IndentationScope are the semantically important part, not the whitespace. This appears to be addressed by #3.
• The number of spaces used for one level of indentation is hard-coded relatively deep in the generator, instead of being configurable.
• The name formatting scheme used to implement functionality is hard coded at the generation site, e.g. with delegate generation. From the changes on #3 notice the repeated use of "Delegate_"/"Delegates_":

  autoimplement/AutoImplement/StubBuilder.cs

  Lines 224 to 230 in fc4e0db

  	writer.Write($"public delegate {method.ReturnType} {method.Name}Delegate_{typesExtension}{method.GenericParameters}({method.ParameterTypesAndNames});");
  	writer.Write($"private readonly Dictionary<Type[], object> {method.Name}Delegates_{typesExtension} = new Dictionary<Type[], object>();");
  	writer.Write($"public void Implement{method.Name}{method.GenericParameters}({method.Name}Delegate_{typesExtension}{method.GenericParameters} implementation)");
  	using (writer.Scope) {
  	writer.Write(createKey);
  	writer.Write($"{method.Name}Delegates_{typesExtension}[key] = implementation;");
  	}