Possibility to generate notifications further in than 1 layer deep?

[CyberBotX]

One of the primary reasons I've been switching to this source generator was to get away from having a high dependence on PostSharp's NotifyPropertyChanged aspect. One issue I have with the source generator is that it only seems to emit calls to OnPropertyChanged a single layer deep.

To explain this better:

[Notify]
bool _changeableProperty;

public bool DependentProperty1 => this.ChangeableProperty;

public bool DependentProperty2 => this.DependentProperty1;

While I get the expected code being emitted of OnPropertyChanged being called on DependentProperty1 when ChangeableProperty is changed, there is absolutely nothing being emitted to make it so OnPropertyChanged is called for changes in either ChangeableProperty or DependentProperty1.

Somewhat related is that properties from parent classes also don't have a notification chain.

To explain that one better too:

partial class ParentClass
{
	[Notify]
	bool _changeableProperty;
}

partial class ChildClass : ParentClass
{
	public bool ChildProperty => this.ChangeableProperty;
}

There will be nothing in the ChildClass to allow its ChildProperty to get a notification that the parent's ChangeableProperty was changed.

Now I'm not sure if this is something that can be solved within a source generator or not or if this would be some limitation of the whole thing.

Basically I wanted to see if these situations are something that the generator can handle automatically, or if there was some way around it (even if it involves adding some extra attributes to do so).

[canton7]

there is absolutely nothing being emitted to make it so OnPropertyChanged is called for changes in either ChangeableProperty or DependentProperty1

No event is raised for DependentProperty2 when ChangeableProperty is set it's true: that should be relatively easy to fix, it's just not something I'd considered. You can easily add it in with attributes for now.

I don't follow how you're expecting DependentProperty1 to be changed itself though, since it's read-only?

I considered supporting automatic inheritance. It gets a bit annoying though: the parent can't assume knowledge of the child property to notify (it might have multiple children), so the best I could come up with was making OnPropertyChanged virtual, overriding it in the child, and switching on the property name passed to see if it's one of the parent's properties. Except that doesn't necessarily work I guess, as the child could be shadowing a parent property, so you won't know whether a name refers to the parent or child version.

Other complicating factors are the base class being in another assembly, the base class not being generated by PropertyChanged.SourceGenerator (maybe even raising events directly from property setters), and the user overriding OnPropertyChanged themselves in the child class in order to do something.

I think it's an easier problem with a weaver, as you can do things like subscribing to the parent's PropertyChanged event on the ctor, which gives you a nice stable interface to work with. Or you can add additional hidden methods without the user getting annoyed that you're cluttering their class with junk.

It's solvable currently with the AlsoNotify attribute, and the README does list this as a limitation.

If you've got some good ideas for how to actually implement this, let's have a discussion. When I last looked at it, it was a lot of effort for something which no-one had asked for!

[CyberBotX]

Regarding me saying that DependencyProperty1 changed, I meant more that changing ChangeableProperty would emit a notification that DependencyProperty1 changed which should in turn emit a notification that DependencyProperty2 changed.

If I used the AlsoNotify attribute, how would I apply it to that second scenario I brought up of having a parent and child class and wanting the child class to be notified if the parent property changes? If I have to put the attribute on the parent class, that sounds like it would only work if the parent is always inherited by a child that has the property requested.

As for ideas on how to implement this, I wish I could help there. I have not made my own source generators so I don't know how much they can actually do or what limitations exist with using them. I'm only a consumer of them.

[canton7]

I meant more that changing ChangeableProperty would emit a notification that DependencyProperty1 changed which should in turn emit a notification that DependencyProperty2 changed.

Aha I see. DependencyProperty1 has no setter, so there's no way to emit anything there. ChangeableProperty would have to emit all 3 events, but that's fine.

If I have to put the attribute on the parent class, that sounds like it would only work if the parent is always inherited by a child that has the property requested.

Well, in the other cases, the parent just emits a pointless event. Annoying but harmless.

As for ideas on how to implement this, I wish I could help there. I have not made my own source generators so I don't know how much they can actually do or what limitations exist with using them

Source generators can only generate source (and emit diagnostics). That's it. They can just emit extra files which are added to the compilation, the ones you see in the solution explorer. So any solution here has to be achieved just by adding extra members to another partial part of the class in question.

I think if we do this by adding stuff to OnPropertyChanged, we'll have to forbid the user from overriding this themselves, at least if we need to notify when a base class property changes. That's a change from the current policy of letting a user override this if they want to: we'd have to provide another mechanism for the user to add their own code there. Alternatively we could generate a different virtual method in the base class and override it in the child class, but that means that the base class needs to have PropertyChanged.SourceGenerator involved (in order to generate this method on the base class), which is limiting.

I could generate a parameterless ctor in the child and subscribe to the base's PropertyChanged event, but that only works if the user doesn't define one themselves. In that case I could force them to call an initialisation method when I emit from their ctor using a diagnostic, but that's ugly.

Subscribing to the PropertyChanged event is also potentially problematic: some frameworks define a ViewModel base class which ensures that PropertyChanged events are raised on the UI thread, so we might be raising events for dependent properties after a thread dispatch, which is unexpected.

[CyberBotX]

Yeah, that all sounds like it would be a mess regardless of the situation. I suppose for my case I could always just add code into my own OnPropertyChanged method to raise the change on the properties that can't be picked up by the source generator. Not a big deal, annoying but I can live with that.

[canton7]

Recursive auto DependsOn support added: fe3ea97

For properties in base classes, requiring that those properties be virtual is another way forward, they can be overridden in the child class. However the overridden setter will need to see whether the value of the property has changed, in addition to the base setter doing the same thing, which gets ugly.

I'm leaning towards forbidden the user from overriding OnPropertyChanged themselves, and instead providing a hook that the SG will call.

[CyberBotX]

Sounds reasonable to me. Although I'm override OnPropertyChanged right now, I don't mind the idea of using a hook instead.

[canton7]

This has been released as v1.0.2