Closed GerardSmit closed 1 month ago
Hi @GerardSmit,
First of all, thank you for integrating this into other libraries!!!
Here are my thoughts:
ClassName
is definitely a better option, because if you had this property on a method attribute, it could be confused with a method name. For example if a library doesn't follow standard naming and has Task MyAsyncMethod()
, a Name
or a MethodName
property could be used to generate void MyMethod()
ClassName
involve namespace? How are nested classes handled?
This PR adds the ability to add
[CreateSyncVersion]
to classes and renaming the resulting class/method name.Problem
I'm trying to make an async file system for the library Zio, but I'm trying not to duplicate code from the async and sync filesystem.
The design is as following:
The interface IAsyncFileSystem has all the async-methods.
The interface IFileSystem implements IAsyncFileSystem and has all the sync-methods.
The implementation of the async file system contains the async methods:
The implementation of the sync file system overrides the async methods and calls the sync versions:
The class doesn't have the sync version of
ReadAllTextAsync
andWriteAllTextAsync
and I want to generate them.However, the source generator doesn't currently have the ability to generate the methods to a different class. Only the current class.
Solution
This PR adds two things:
[CreateSyncVersion]
can be added to classes to generate sync-versions of methods of all methods in the class.[CreateSyncVersion]
has a new parameter to override the auto-generated name, this can be used for the class.For the problem I can now add
[CreateSyncVersion]
to the class and override the class name:Which generates the following code:
Test.Test.FileSystem.WriteAllTextAsync.g.cs
Test.Test.FileSystem.ReadAllTextAsync.g.cs
Considerations
I could also add a new argument called
ClassName
instead ofName
and disallow[CreateSyncVersion]
on classes. Feel free to discuss this in this PR 😄