Using Source Generators to create methods

[mrlacey]

Following on from #142 (comment)

What's the benefit of using Source Generators here?

Doesn't it make testing and documenting of the available functionality harder?

In that the amount of effort to write the code for the generator is approximately equivalent to writing the methods that would be generated directly, the fact that what will be generated will (almost?) always be the same it looks like work is being unnecessarily duplicated and offloaded to the consumer of the library when it could be done once.
It's the difference between writing and compiling the code once when the library is created, or generating and compiling that code every time every consuming app is built. That feels like a waste of compilation effort by duplicating the task (even though, admittedly very small) for every app that's built rather than just doing it once when the library is created.

The only benefit I see with the way that the current Source Generator implementation works with ITextAlignment means that it it will automatically add support for any new controls in the Microsoft.Maui.Controls assembly that also implement this interface.
However I'd expect (although I haven't yet checked) it would be possible to achieve the same things by building an extension based on the interface.

It feels like the use of Source Generators is unnecessary and doesn't really add any real benefit. It just makes the codebase more complicated as there are some features and required markup functionality that can't be created this way.

[brminnick]

However I'd expect (although I haven't yet checked) it would be possible to achieve the same things by building an extension based on the interface

You've actually nailed the problem! All of the interfaces in .NET MAUI are read-only; the interface properties only have getters, no setters.

So the only way to set a property based on the usage of a Microsoft.Maui interface and ensure we cover every usage of the interface in both .NET MAUI and the user's custom controls is to use Source Generators to detect the interface and generate the extension methods.

[bijington]

It does sound like just writing the code will be the best approach. Especially as we need to document it too

[mrlacey]

Yes, for custom controls that implement an interface (such as ITextAlignment) and that you want to provide methods for, a SourceGenerator is a great solution.
My concern is using that for the controls in the Microsoft.Maui.Controls assembly.

How much support there should be for custom and 3rd party controls doesn't seem to have been documented or discussed (apart from, minimally, at #86).

[pictos]

@mrlacey, actually using SGs (Incremental Source Generators, in this case) can be less code to maintain and more flexibility. So for reference, I'll take your PR #141, here all the methods just grab a value, set it to the property, and return the object, as in the snippet below:

public static TVisualElement Width<TVisualElement>(this TVisualElement element, double widthRequest) where TVisualElement : VisualElement
{
	element.WidthRequest = widthRequest;
	return element;
}

So in this case we do it for all properties inside VisualElement.

From a general point of view, you can say that SG is a reflection for the compile time, you can access all members and info on an object, that said, with SGs here, we can create a for loop that will emit those methods for all public properties inside the VisualElement, and the method will set the property and return the object.

What's the benefit of using Source Generators here?

So at the end of the day, we will have one code that will generate those methods and if in the future .NET MAUI add more properties, the SG will see that and generate the methods, so we don't need to open a PR adding more extensions methods. Of course, there are cases where writing down the methods is a best solution, for cases like this having a SG, IMHO is better.

or generating and compiling that code every time every consuming app is built.

This isn't true, because we use Incremental Source Generators, so the code generation will occours just when something changed. So for controls that are inside .NET MAUI the generation will happens just once. For customControl the generation will happen just when the dev change something that requires a code generation, for example creating or editing a property.

It feels like the use of Source Generators is unnecessary and doesn't really add any real benefit. It just makes the codebase more complicated as there are some features and required markup functionality that can't be created this way.

Why do you've this feeling? TBH, writing a SG for this isn't that hard. If you never wrote one I'll be more than happy to guide you through the process (if we choose to re-implement your PR using SG)

[idexus]

@bijington

I was under the hopeful impression that we could/would generate the source once when we build and then ship the resulting library. Perhaps this was a misunderstanding on my part.

The code is generated once and then it can be sent together with the library, you can of course attach the generator to the library but then it is executed only on user types. This is what I did in my library to cover all properties and event handlers for all classes from Microsoft.Maui.Controls down to the `BindableObject' class

Documentation can also be generated with a little effort based on documentation from the MAUI project

[pictos]

@idexus, I saw that in your lib you use the ISourceGenerator instead of IIncrementalSourceGenerator, so your classes aren't generated just once. I would say it will generate the types every time something in the project changes. Anyway I recommend you to update your lib to use the new IIncrementalSourceGenerator.

[idexus]

@pictos Thanks, I'll have to do that over time as I also generate code based on user defined classes.

What I meant was that for already compiled libraries, when compiling a project using them, the generator for them is not restarted. I tested it.

[pictos]

@idexus do you think we can continue the discussion here or should I create a new one?

[idexus]

@pictos we can stay here or create a new discussion about broader use of SG in the context of creating a new foundation to cover all properties and create inline builders for them to create property bindings, theme dependency, platform etc. I will also be opening PR dotnet/maui#12678 for adding IEnumerable interface in maui project for classes with [ContentProperty] attribute, so we can do the rest by extension methods :)

[CliffAgius]

Closed as per the Community Stand-up discussion here: https://youtu.be/N9wMcBP4jtg?t=2889