Add a Set<T> method to Screen and PropertyChangedBase

[caliburn-micro]

Add a Set method to Screen and PropertyChangedBase

from caliburn.micro.

[Athari]

Usually I add several overloads:

[NotifyPropertyChangedInvocator ("propName")]
protected bool Set<T> (ref T field, T value,
        [CallerMemberName] string propName = null)

[NotifyPropertyChangedInvocator ("propNames")]
protected bool Set<T> (ref T field, T value,
        params string[] propNames)

[NotifyPropertyChangedInvocator ("propName")]
protected bool SetAndValidate<T> (ref T field, T value, Action validate,
        [CallerMemberName] string propName = null)

NotifyPropertyChangedInvocatorAttribute is for ReSharper to recognize strings as property names and support code analysis and refactoring (renaming properties, converting simple properties to properties with notification etc.). With these overloads and attributes, implementing INotifyPropertyChanged is SO much easier.

It would be awesome if attributes were included too. ReSharper will recognize any attribute with the following implementation:

[AttributeUsage(AttributeTargets.Method, AllowMultiple = false, Inherited = true)]
public sealed class NotifyPropertyChangedInvocatorAttribute : Attribute
{
    public NotifyPropertyChangedInvocatorAttribute () { }
    public NotifyPropertyChangedInvocatorAttribute (string parameterName)
    {
        ParameterName = parameterName;
    }

    public string ParameterName { get; private set; }
}

It's just one lightweight attribute, so it shouldn't be a problem.

[tibel]

ReSharper supports Caliburn.Micro out of the box without the attributes. It would be better to tell JetBrains that they should add the method to their package https://resharper-plugins.jetbrains.com/packages/ReSharper.ExternalAnnotations/

[PhilPJL]

I only put one overload as an example.

I've gone withy using the extension method approach since this then applies nicely to Screen and Conductor and anything else that implements INotifyPropertyChangedEx. Unfortunately R# doesn't pick up extension methods with the NotifyPropertyChangedInvocatorAttribute. I've raised a issue in their bug tracker.

[Athari]

If anyone wonders, here's the issue Philip created in ReSharper's issue tracker. Please vote up!

I'd prefer built-in Set method though. It makes property syntax so much nicer (and more performant, compared to the default patern "assign, notify").

[mwpowellhtx]

I like to use a Set method of some sort, usually, when any of the NPC interfaces are in play (INotifyPropertyChanged, INotifyPropertyChanging).

I dislike CallerMemberNameAttribute. I appreciate it's there, but feel it is a half measure, does not fully address the problem knowing what to notify. I usually like some sort of Expression<Func<T, TProperty>>, where T is the instance, usually, and TProperty is the property type, with usage something like.

I usually like to do a setter something like this:

void Set<TField, TProperty>(ref TField field,
    TField value,
    Expression<Func<TProperty>> property,
    Func<TField, TField, bool> changing)
{
    //...
}

Sometimes pass in a before and after action so I can notify about related properties changing, if necessary.

void Set<TField, TProperty>(ref TField field,
    TField value,
    Expression<Func<TProperty>> property,
    Func<TField, TField, bool> changing = null,
    Action<TField, TField> before = null,
    Action<TField, TField> after = null)
{
    //...
}

Default behavior is either do nothing or return true, always changing. TField may necessarily be different from TProperty depending on the property and field in play. This also depends on there being a backing field.

The nice thing about this approach is that, with some run-time Reflection cost, there is a built-in check that the property(ies) and their names will mesh through the PropertyInfo, without having to chase them. As well as for potentially secondary properties changing.

Could potentially have a version that recognized the auto-property, type thing. Although usually I am operating through field-backed-properties.

void Set<TProperty>(Expression<Func<TProperty>> property,
    Func<TProperty, TProperty, bool> changing = null,
    Action<TProperty, TProperty> before = null,
    Action<TProperty, TProperty> after = null)
{
    //...
}

With the notification method itself supporting something akin to:

void RaiseNotifyPropertyChanging<TProperty>(Expression<Func<TProperty>> property)
{
    //...
}

But, that's just me.

[evnik]

Could it be implemented even without ReSharper support? Actually, I don't use ReSharper, but I just want to call Set methods, like I can do it with other MVVM frameworks.

[nigel-sampson]

@evnik you can create an extension method with Set functionality with no problems at all. The R# discussion is just about ways to inform R# that this method exists for auto-refactoring options.

Given that most people want different things from methods like this I'd still thinking it should be an external extension method that people can do what they want with.

Opinions can change though.

[evnik]

@nigel-sampson Yes, I can write an extension method (or non-extension method in my derived classes) and copy it into each of my project. But I don't understand why couldn't we have a single implementation inside the framework?

[nigel-sampson]

@evnik mainly because from just in this thread there are four different implementations and I know of about four others from chatting with people. Everyone has a different opinion on what this method should look like so in my opinion it's best left to the individual developer.

Personally I use Fody.PropertyChanged.

This is the sort of method that ends up in every companies core assemblies and doesn't end up being copied.