Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider using partial properties #121

Open
giard-alexandre opened this issue Nov 7, 2024 · 8 comments
Open

Consider using partial properties #121

giard-alexandre opened this issue Nov 7, 2024 · 8 comments

Comments

@giard-alexandre
Copy link

Is your feature request related to a problem? Please describe.

With the release of dotnet 9 and C# 13 right around the corner, I was wondering if anyone had considered adding support for the new partial properties syntax.
I have VERY limited (read: almost none) experience with Source Generators, so I'll apologize right away if this is a dumb idea!

Describe the solution you'd like

Using partial properties, it SHOULD be possible to allow us to define [Reactive] properties using the property itself instead of a field. Ex:

public partial class C
{
    [Reactive]
    public partial string Name { get; set; }
}

Describe alternatives you've considered

The current way of doing things works (of course), it's just less explicit since you just need to expect the Property to be generated properly.

Describe suggestions on how to achieve the feature

Additional context

Some (hopefully) useful links:

@ChrisPulman
Copy link
Member

This has been considered, and will become an excellent option once c#13 is available, we also need to cater for those who are stuck a few visual studio versions behind though so it may take some time before this option becomes viable.

@giard-alexandre
Copy link
Author

Understandable!
Would it not be possible to make this available conditionally if a projects C# version is >= 13?
That would allow people on older versions to keep using it in the old way but newer versions would be able to leverage this new method 😄

@glennawatson
Copy link
Contributor

glennawatson commented Nov 8, 2024

We can target higher versions of roslyn, the community toolkit does it. Multi targetting is done based on the nuget package directory structure. In the Roslyn 4.12 version we can detect partial properties.

@glennawatson
Copy link
Contributor

eg

    <None Include="..\CommunityToolkit.Mvvm.SourceGenerators.Roslyn4001\bin\$(Configuration)\netstandard2.0\CommunityToolkit.Mvvm.SourceGenerators.dll" PackagePath="analyzers\dotnet\roslyn4.0\cs" Pack="true" Visible="false" />
    <None Include="..\CommunityToolkit.Mvvm.SourceGenerators.Roslyn4031\bin\$(Configuration)\netstandard2.0\CommunityToolkit.Mvvm.SourceGenerators.dll" PackagePath="analyzers\dotnet\roslyn4.3\cs" Pack="true" Visible="false" />
    <None Include="..\CommunityToolkit.Mvvm.SourceGenerators.Roslyn4110\bin\$(Configuration)\netstandard2.0\CommunityToolkit.Mvvm.SourceGenerators.dll" PackagePath="analyzers\dotnet\roslyn4.11\cs" Pack="true" Visible="false" />

@glennawatson
Copy link
Contributor

@giard-alexandre we have a couple high critical bugs to fix at the moment before new functionality can come around (and thanks @ChrisPulman for taking most of the effort for this).

There will be a bit of playing around with project structures to get this to work properly but likely I suspect it'll be the case of creating a new roslyn4.12 project, and then using the SyntaxNode's for the new partial properties.

Definitely probably valuable getting this done since then we get much more closer to the original Fody approach and way more cleaner.

@giard-alexandre
Copy link
Author

Definitely agree that it does look cleaner and makes porting from the Fody version much easier!
I appreciate you taking the time to add these details too, always nice to learn how these projects work. I look forward to future versions of the lib!

Quick side-note that would probably be more relevant in a Discussion but they are not available in this repo 😬 :
What would you say are the biggest advantages of using these SourceGenerators over the Fody implementation?
Off the top of my head, I can think of code readability/easier to debug but I'd be curious to know your opinions!

@glennawatson
Copy link
Contributor

glennawatson commented Nov 8, 2024

Turned on discussions now. Big thing is fody is all about IL modification and injection, so definitely harder to get right.

I was in the midst of re-writing the rxui fody at one stage, and got it more reliable with a lot of use case

But us detecting a pattern in the syntax nodes and then acting on it, makes it much easier.

Advantage Fody has over source generators is the fact they modify existing IL code

In theory interceptors allow this type of functionality though.

First place I've seen it used is in minimal API in .NET 8 where they intercept the map methods and generate a map graphing.

@giard-alexandre
Copy link
Author

Awesome! Thanks again for the info! I'll be watching this project and the other rxui projects closely :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants