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

·>json обычно не просто так json, а для обмена данными с другими системами, поэтому пишется какой-нибдуь swagger,avro,etc и по нему генерится код .

Ага. Обычно. У меня только обычно даже по присланной json schema ничего дельного не генерируется. Потому что и схема отличается от реальности и формат специфически продуман.
В итоге проще написать всё вручную, нежели сначала возиться с настройкой генерации, а потом всё перелопачивать и перепроверять.

·>Код маппинга строк генерится из схемы БД.

Разве что для банального CRUD это подойдёт, т.к. помимо select * в реальном приложении будет куча выборок произвольных данных

·>И что? Это уже задача ЯП выдавать ошибки компиляции, если что не так. И, вроде, вполне справляется.

Я к тому, что в итоге field описан в начале файла, getter — в середине, setter — в конце.
Нужна дисциплина всех разработчиков, чтобы такого не было и можно было легко посмотреть логику получения значений и изменения.

·>Ибо нехрен.

Что нехрен? Добавлять в setter'ы валидацию данных, например?

·>Если уж очень надо, то такие методы умеет IDE писать за тебя.

Но не умеет их потом поддерживать.

·>Грубо говоря, если свести к абсурду, нам не нужна поддержка в ЯП ВУ метода "void printHelloWorld()" для которого будет сразу генериться весь нужный код, хоть это и упрощает написание кода в некоторых случаях.

Тогда и методы не нужны, ведь есть функции, просто в них неявно this-объект передаётся.

·>Вот здесь смотри картинку в вопросе, обрати внимание на номера строк. Тривиальные сеттеры-гетеры задетектились и заколлапсились.

Ну, и в итоге 3 отдельных строки, а не 1, как было бы со свойством. И между get/set может быть сколько угодно строк кода.

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

K>·>json обычно не просто так json, а для обмена данными с другими системами, поэтому пишется какой-нибдуь swagger,avro,etc и по нему генерится код .
K>Ага. Обычно. У меня только обычно даже по присланной json schema ничего дельного не генерируется. Потому что и схема отличается от реальности и формат специфически продуман.
За такое надо по рукам давать.

K>В итоге проще написать всё вручную, нежели сначала возиться с настройкой генерации, а потом всё перелопачивать и перепроверять.
Плохой подход, непродуктивный.

K>·>Код маппинга строк генерится из схемы БД.
K>Разве что для банального CRUD это подойдёт, т.к. помимо select * в реальном приложении будет куча выборок произвольных данных
Для выборок проперти не нужны. Нужны read-only структуры.

K>·>И что? Это уже задача ЯП выдавать ошибки компиляции, если что не так. И, вроде, вполне справляется.
K>Я к тому, что в итоге field описан в начале файла, getter — в середине, setter — в конце.
K>Нужна дисциплина всех разработчиков, чтобы такого не было и можно было легко посмотреть логику получения значений и изменения.
Я уже забыл такую проблему со времён когда приходилось использовать нотепад для работы с кодом.

K>·>Ибо нехрен.
K>Что нехрен? Добавлять в setter'ы валидацию данных, например?
Угу. Валидацией данных должны заниматься валидаторы, а не мапперы. Или уж сразу с типами писать: не иметь SetEmail(string value) с логикой валидации, а иметь SetEmail(Email value).

K>·>Если уж очень надо, то такие методы умеет IDE писать за тебя.
K>Но не умеет их потом поддерживать.
Умеет, конечно, как и любой другой метод.

K>·>Грубо говоря, если свести к абсурду, нам не нужна поддержка в ЯП ВУ метода "void printHelloWorld()" для которого будет сразу генериться весь нужный код, хоть это и упрощает написание кода в некоторых случаях.
K>Тогда и методы не нужны, ведь есть функции, просто в них неявно this-объект передаётся.
Если в ЯП нет виртуальных функций, то верно.

K>·>Вот здесь смотри картинку в вопросе, обрати внимание на номера строк. Тривиальные сеттеры-гетеры задетектились и заколлапсились.
K>Ну, и в итоге 3 отдельных строки, а не 1, как было бы со свойством. И между get/set может быть сколько угодно строк кода.
Не вижу в этом проблемы при наличии чего-то получше нотепада.

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

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

_NN>>С квадратными можно новые правила придумать.
_NN>>А со старым синтаксисом менять правила это сломать рабочий код.

C>Вот на этот счет у меня большие сомнения.

Тогда вам в C# language discussions.
Напишите предложение как сделать так, чтобы со старым синтаксисом работало и если действительно нет с этим проблем, разработчики будут только рады.
Это улучшит производительность без изменения кода.

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

_NN>Напишите предложение как сделать так, чтобы со старым синтаксисом работало и если действительно нет с этим проблем, разработчики будут только рады.

Не будут. Они уже сделали решение сделать новый синтаксис, а если сказать им, что решение было неверным — будут биться до последнего вздоха.
Ты вчера родился?

M>·>Так я хочу сказать, о том как добавление абсолютно бесполезного сахара ведёт к поломке действительно удобной фичи оверлоада методов. Сабж, однако.

M>Могу предположить, что MS предусмотрел какой-нибудь атрибут, которым авторы библиотеки могут пометить одну из перегрузок для устранения ambiguity.

OverloadResolutionPriorityAttribute

Правда как я понял изначально про это забыли и атрибут только в последней версии добавили.

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

K>WPF — редкостная шляпа. Идея интересная, реализация ужасная и заброшен недоделанным.

Я первые 2 года (примерно) тоже так думал, потом сильно поменял отношение:

• простота разметки интерфейса (вёрстка интерфейса, как на HTML),
  
• простота создания анимаций,
  
• из коробки разделение на GUI и модель решают.

Особенно последнее: сопровождать MVVM сильно проще чем что-либо на WinForms или VCL — самопальщина и рядом не лежала.

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

vsb>>Так C# же с рождения такой — эдакая недо-Java, в которую тащут всё блестящее.

JAVA — это C# без структур и, как следствие, без PInvoke. Из этого мноооого чего вытекает.
Вывод жаба — недошарп.

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

Ф>простота разметки интерфейса (вёрстка интерфейса, как на HTML),

Совсем не как в HTML, да и HTML не так, чтобы был хорошим решением.
В каком-нибудь Grid'е по ячейкам распихивать контролы — такое себе удовольствие.
Нужно потом посередине строку добавить и сиди у половины из них меняй номер в Grid.Row.

Ф>простота создания анимаций,

Как-то не нужно, не пользуюсь. Смотрел всякие стандартные ProgressBar и т.п. В итоге часть логики в XAML расписана, часть в коде на C#.
Я удобства не заметил, прикола не понял.

Ф>из коробки разделение на GUI и модель решают.

В том и проблема, что из коробки ничего нет.
Допустим, есть во ViewModel свойство bool IsActive.
Нужно на основании него показать/скрыть контрол.
Просто так биндинг сделать нельзя, т.к. Visibility — это enum с тремя значениями, а не bool.
Как в Razor Pages нельзя вставлять куски кода на C# или хоть какие-то простые выражения писать.
Есть вариант — конвертер написать, добавить его в ресурсы и прокинуть в биндинг.
Либо можно стиль определить с триггером, что тоже очень быстро и удобно делается.
Ну, либо с расширениями разметки играться.
Удобного решения из коробки нет.
Нужна банальная инверсия bool-значения — всё то же самое, в xaml это просто так сделать нельзя.
Валидации нормальной тоже из коробки нет, есть три заготовки и у всех свои недостатки и нюансы.
Механизма как из ViewModel показать другую ViewModel в новом окне тоже нет.
Да хоть какого-то адекватного механизма обмена от ViewModel к View — нет.
100500 событий создавать и подписываться на них — такое себе.
PropertyChanged для биндинга уже хватает, для которого опять же стандартного механизма нет и везде свои велосипеды для выбрасывания события при изменении свойства.
В итоге нужно целый фреймворк пилить, чтобы этим самым WPF хоть как-то нормально пользоваться.