Ramon de Klein

My feedback

  1. 8 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    3 comments  ·  Visual Studio IDE » Languages - C#  ·  Flag idea as inappropriate…  ·  Admin →
    Ramon de Klein commented  · 

    It's generally bad programming practice to enforce constructor prototypes so strict. It makes dependency injection much harder, because you cannot inject additional arguments.

    Interface are about how an object can be used, not how it should be created. I agree that it would be useful in the ISerializable example, but I think ISerializable is bad as well. Using a separate factory that would create the object from serialization info/context would have been much better.

  2. 2,638 votes
    Vote
    Sign in
    (thinking…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    35 comments  ·  Visual Studio IDE » Languages - C#  ·  Flag idea as inappropriate…  ·  Admin →
    Ramon de Klein supported this idea  · 
    Ramon de Klein commented  · 

    Implementing INotifyPropertyChanged properly requires some repeating programming effort for each property. It also used to be error-prone, but this can be resolved in C# 5 using the CallerMemberName attribute. It would be more convenient to use automatic properties with INotifyPropertyChanged support. The 'SupportINotifyPropertyChanged' attribute can be applied to automatic properties and this result in the following code:

    [SupportINotifyPropertyChanged]
    public string Description { get; set; }

    Is compiled to something like this:

    private string __description;
    public Description
    {
    get { return __description; }
    set {
    if (__description == value) return;
    __description = value;
    var propChanged = (INotifyPropertyChanged)this; /* prevents race condition */
    if (propChanged != null)
    propChanged(this, new PropertyChangedEventArgs("Description"));
    }
    }

    A compilation error will be emitted if the class (or one of its parents) doesn't implement the INotifyPropertyChanged interface.

    As an addition the 'SupportINotifyPropertyChanged' attribute could also take an optional Func<T,T,bool> delegate (or use IEqualityComparer<T>) that is used to check if the new value is different for more complex scenarios.

    Ramon de Klein commented  · 

    Implementing INotifyPropertyChanged properly requires some repeating programming effort for each property. It also used to be error-prone, but this can be resolved in C# 5 using the CallerMemberName attribute. It would be more convenient to use automatic properties with INotifyPropertyChanged support. The 'SupportINotifyPropertyChanged' attribute can be applied to automatic properties and this result in the following code:

    [SupportINotifyPropertyChanged]
    public string Description { get; set; }

    Is compiled to something like this:

    private string __description;
    public Description
    {
    get { return __description; }
    set {
    if (__description == value) return;
    __description = value;
    var propChanged = (INotifyPropertyChanged)this; /* prevents race condition */
    if (propChanged != null)
    propChanged(this, new PropertyChangedEventArgs("Description"));
    }
    }

    A compilation error will be emitted if the class (or one of its parents) doesn't implement the INotifyPropertyChanged interface.

    As an addition the 'SupportINotifyPropertyChanged' attribute could also take an optional Func<T,T,bool> delegate (or use IEqualityComparer<T>) that is used to check if the new value is different for more complex scenarios.

Feedback and Knowledge Base