Сообщение Re[2]: Багофича C# - object initializer от 23.07.2024 13:18
Изменено 23.07.2024 13:40 Baiker
Re[2]: Багофича C# - object initializer
Здравствуйте, Sinclair, Вы писали:
B>>PS
B>>А я ведь ещё на заре этой дебильной фичи предлагал: не надо этой узколобой привязки инициализатора к конструктору!!
S>Наверное, то, что предлагаемый вами подход создаёт больше проблем, чем решает. В частности, не очень понятно, как быть с вложенными инициализаторами.
По моему конкретному варианту в постскриптуме — вам нравится его реализация? Если нет — давайте обсудим возражения. Если нравится, давайте в рамках предложенного синтаксиса посмотрим на конкретный пример, где "создаёт больше проблем, чем решает". По-моему, как раз мой вариант стократ универсальнее мелкомягкого (напомню — он помогает вообще ВЕЗДЕ в коде, а не только после new).
B>>PS
B>>А я ведь ещё на заре этой дебильной фичи предлагал: не надо этой узколобой привязки инициализатора к конструктору!!
S>Наверное, то, что предлагаемый вами подход создаёт больше проблем, чем решает. В частности, не очень понятно, как быть с вложенными инициализаторами.
По моему конкретному варианту в постскриптуме — вам нравится его реализация? Если нет — давайте обсудим возражения. Если нравится, давайте в рамках предложенного синтаксиса посмотрим на конкретный пример, где "создаёт больше проблем, чем решает". По-моему, как раз мой вариант стократ универсальнее мелкомягкого (напомню — он помогает вообще ВЕЗДЕ в коде, а не только после new).
Re[2]: Багофича C# - object initializer
Здравствуйте, Sinclair, Вы писали:
B>>PS
B>>А я ведь ещё на заре этой дебильной фичи предлагал: не надо этой узколобой привязки инициализатора к конструктору!!
S>Наверное, то, что предлагаемый вами подход создаёт больше проблем, чем решает. В частности, не очень понятно, как быть с вложенными инициализаторами.
По моему конкретному варианту в постскриптуме — вам нравится его реализация? Если нет — давайте обсудим возражения. Если нравится, давайте в рамках предложенного синтаксиса посмотрим на конкретный пример, где "создаёт больше проблем, чем решает". По-моему, как раз мой вариант стократ универсальнее мелкомягкого (напомню — он помогает вообще ВЕЗДЕ в коде, а не только после new).
Вот интересный пример со вложенностью, но я тут "множества нерешённых проблем" не вижу, дополняйте:
B>>PS
B>>А я ведь ещё на заре этой дебильной фичи предлагал: не надо этой узколобой привязки инициализатора к конструктору!!
S>Наверное, то, что предлагаемый вами подход создаёт больше проблем, чем решает. В частности, не очень понятно, как быть с вложенными инициализаторами.
По моему конкретному варианту в постскриптуме — вам нравится его реализация? Если нет — давайте обсудим возражения. Если нравится, давайте в рамках предложенного синтаксиса посмотрим на конкретный пример, где "создаёт больше проблем, чем решает". По-моему, как раз мой вариант стократ универсальнее мелкомягкого (напомню — он помогает вообще ВЕЗДЕ в коде, а не только после new).
Вот интересный пример со вложенностью, но я тут "множества нерешённых проблем" не вижу, дополняйте:
int Width = 7;// обычная переменная в outer scope
var btn = new Button init B { // внимание! 'B' - это alias для создаваемого объекта (во внешнем scope это btn)
.Width = Width + 50;// Button.Width = Width + 50 = 57
.Invalidate();// такое MS не сделала даже за 20 лет!
.Height = .Width + 1;// очевидно, что справа от = всё тот же контекст - взяли внутреннего мембера .Width
.Children.Add(niceIcon);
.Styles = new HTMLStyle init { // как и просили, вложенный init
.CSS = "color: #" + .Color;// Button.Color взят извне, т.к. HTMLStyle его не содержит
.File = 1;// error! Нет такого мембера ни у HTMLStyle, ни у Button, внешний scope не рассматривается
.Length = B.Length - 7;// ага! Вот где alias нужен. Вот теперь это HTMLStyle.Length = Button(B).Length - 7
};
};