Господа, прошу высказаться по поводу того, что лично вам не нравится в реализации DependencyProperty. Есть мнение, что в рамках функциональности DependencyProperty реализовать аналог лучше, чем реализован в Ms, практически нереально. Если бы вы делали DependencyProperty, как бы вы их делали?

Мой вариант в виде C# псевдокода, описывающий основную идею, как видно максимум чего я добился пока — это типизация и отказ от упаковки/распаковки:

  class Element
  {
    static Property<double> widthProperty;

    static Element ( )
    {
      widthProperty = Property ( _ => _.Width, ( ) => new Element ( ), double.NaN, ( s, v ) => s.OnWidthChanged ( v ) );
    }

    [Options ( Options.Measure | Options.Render | Options.Arrange )]
    public double Width
    {
      get { return GetValue ( widthProperty ); }
      set { SetValue ( widthProperty, value ); }
    }

    protected T GetValue<T> ( Property<T> property )
    {
      return default ( T );
    }

    protected void SetValue<T> ( Property<T> property, T value )
    { 
    
    }

    private void OnWidthChanged ( double newWidth )
    {

    }

    private static Property<T> Property<O, T> ( Expression<Func<O, T>> property, Expression<Func<O>> ownerType,
      T defaultValue, Action<O, T> changed )
    {
      return null;
    }
  }

  class Property<T> { }

  [Flags]
  enum Options
  {
    Render,
    Measure,
    Arrange
  }

  [AttributeUsage ( AttributeTargets.Property )]
  class OptionsAttribute : Attribute
  {
    public OptionsAttribute ( Options options ) { this.Options = options; }

    public Options Options { get; private set; }
  }

Здравствуйте, Visor2004, Вы писали:

V>Господа, прошу высказаться по поводу того, что лично вам не нравится в реализации DependencyProperty. Есть мнение, что в рамках функциональности DependencyProperty реализовать аналог лучше, чем реализован в Ms, практически нереально. Если бы вы делали DependencyProperty, как бы вы их делали?
В DependencyProperty не нравится два момента. Первое — это невозможность положить Binding с режимом OneWayToSource в read-only свойство. Вторая — это, конечно же, боксинг. Но упаковки избежать просто не получиться, потому что внутренние механизмы (та же привязка) должны как-то хранить и обмениваться значениями.

V>Мой вариант в виде C# псевдокода, описывающий основную идею, как видно максимум чего я добился пока — это типизация и отказ от упаковки/распаковки:
Пока что ты этого добился на уровне контракта. А реализация? Как будешь хранить значение? Как твой вариант с атрибутами использовать для Attached Properties?

Здравствуйте, MxMsk, Вы писали:

MM>Здравствуйте, Visor2004, Вы писали:

V>>Господа, прошу высказаться по поводу того, что лично вам не нравится в реализации DependencyProperty. Есть мнение, что в рамках функциональности DependencyProperty реализовать аналог лучше, чем реализован в Ms, практически нереально. Если бы вы делали DependencyProperty, как бы вы их делали?
MM>В DependencyProperty не нравится два момента. Первое — это невозможность положить Binding с режимом OneWayToSource в read-only свойство. Вторая — это, конечно же, боксинг. Но упаковки избежать просто не получиться, потому что внутренние механизмы (та же привязка) должны как-то хранить и обмениваться значениями.

Главное добиться на уровне контракта, в реализации почти всегда можно вывернуться. например, можно сделать что-то типа StoredValue<T>, который специфицировать в рантайме с помощью рефлексии.

V>>Мой вариант в виде C# псевдокода, описывающий основную идею, как видно максимум чего я добился пока — это типизация и отказ от упаковки/распаковки:
MM>Пока что ты этого добился на уровне контракта. А реализация? Как будешь хранить значение? Как твой вариант с атрибутами использовать для Attached Properties?
Никак чтоб поддержать attached behavior придется опции задавать параметром в методе Property.

Основной поинт в том, чтобы услышать альтернативные способы реализации. То как люди хотели бы это видеть.

Здравствуйте, Visor2004, Вы писали:

V>Господа, прошу высказаться по поводу того, что лично вам не нравится в реализации DependencyProperty. Есть мнение, что в рамках функциональности DependencyProperty реализовать аналог лучше, чем реализован в Ms, практически нереально. Если бы вы делали DependencyProperty, как бы вы их делали?

Лучше в каком смысле? Когда писался этот код для WPF, .NET был ещё в бете!

Здравствуйте, Vladek, Вы писали:

V>Лучше в каком смысле? Когда писался этот код для WPF, .NET был ещё в бете!

В смысле удобства для разработчика. Как сохранив функционал сделать DependencyProperty более простыми в объявлении и использовании.

Здравствуйте, Visor2004, Вы писали:

V>Главное добиться на уровне контракта, в реализации почти всегда можно вывернуться. например, можно сделать что-то типа StoredValue<T>, который специфицировать в рантайме с помощью рефлексии.
Толку от такого контракта, если реализация не сможет его воплотить? Как хранить StoredValue<T> в одном списке, если он generic?

V>>>Мой вариант в виде C# псевдокода, описывающий основную идею, как видно максимум чего я добился пока — это типизация и отказ от упаковки/распаковки:
MM>>Пока что ты этого добился на уровне контракта. А реализация? Как будешь хранить значение? Как твой вариант с атрибутами использовать для Attached Properties?
V>Никак чтоб поддержать attached behavior придется опции задавать параметром в методе Property.
И получается два разных принципа объявления свойств А еще есть OverrideMetadata...

V>Основной поинт в том, чтобы услышать альтернативные способы реализации. То как люди хотели бы это видеть.
Ну, можно еще добавить, что задалбывает писать строковые имена свойств в Register. Было бы круто, если бы компилер поддерживал автогенерацию обычных свойств по объявлению DependencyProperty.

Здравствуйте, MxMsk, Вы писали:

MM>Здравствуйте, Visor2004, Вы писали:

V>>Главное добиться на уровне контракта, в реализации почти всегда можно вывернуться. например, можно сделать что-то типа StoredValue<T>, который специфицировать в рантайме с помощью рефлексии.
MM>Толку от такого контракта, если реализация не сможет его воплотить? Как хранить StoredValue<T> в одном списке, если он generic?

V>>>>Мой вариант в виде C# псевдокода, описывающий основную идею, как видно максимум чего я добился пока — это типизация и отказ от упаковки/распаковки:
MM>>>Пока что ты этого добился на уровне контракта. А реализация? Как будешь хранить значение? Как твой вариант с атрибутами использовать для Attached Properties?
V>>Никак чтоб поддержать attached behavior придется опции задавать параметром в методе Property.
MM>И получается два разных принципа объявления свойств А еще есть OverrideMetadata...

V>>Основной поинт в том, чтобы услышать альтернативные способы реализации. То как люди хотели бы это видеть.
MM>Ну, можно еще добавить, что задалбывает писать строковые имена свойств в Register. Было бы круто, если бы компилер поддерживал автогенерацию обычных свойств по объявлению DependencyProperty.

А если было бы сделано как в BLToolkit, объявляем абстрактное CLR свойство, реализацию для которого генерируем в рантайме. Единственный минус такого подхода, так это от что через фабрику потом объекты такие надо получать.

Здравствуйте, Visor2004, Вы писали:

+1. Синтаксис DP это BDSM.

V>А если было бы сделано как в BLToolkit, объявляем абстрактное CLR свойство, реализацию для которого генерируем в рантайме. Единственный минус такого подхода, так это от что через фабрику потом объекты такие надо получать.

Взгляни на примеры для PostSharp — может подскажет какие идеи.
Там тоже догенерируется IL как в BLToolkit, но на этапе сборки, так что можно избежать фабрик для инстанциации.