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

·>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 хоть как-то нормально пользоваться.

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

_NN>Новый синтаскис позволяет вызывать AddRange, что конечно более приемлимо чем вызов Add по отдельности.

Кстати, откуда такая информация? IL никаких AddRange не показывает.

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

_NN>Новый синтаскис позволяет вызывать AddRange, что конечно более приемлимо чем вызов Add по отдельности.

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

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

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

_NN>>Новый синтаскис позволяет вызывать AddRange, что конечно более приемлимо чем вызов Add по отдельности.

C>Так что, есть источники? Потому что дизассемблер ничего подобного не показывает и похоже, что ты просто ляпнул глупость.

https://learn.microsoft.com/ru-ru/dotnet/api/system.collections.generic.list-1.addrange?view=net-8.0

https://learn.microsoft.com/ru-ru/dotnet/api/system.collections.generic.list-1.-ctor?view=net-8.0#system-collections-generic-list-1-ctor(system-collections-generic-ienumerable((-0)))

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

S>https://learn.microsoft.com/ru-ru/dotnet/api/system.collections.generic.list-1.addrange?view=net-8.0
S>https://learn.microsoft.com/ru-ru/dotnet/api/system.collections.generic.list-1.-ctor?view=net-8.0#system-collections-generic-list-1-ctor(system-collections-generic-ienumerable((-0)))

Не может быть!
А какое это имеет отношение к заданному вопросу о синтаксисе?

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

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

_NN>>Новый синтаскис позволяет вызывать AddRange, что конечно более приемлимо чем вызов Add по отдельности.

https://sharplab.io/#v2:CYLg1APgAgTAjAWAFBQMwAJboMLoN7LpGYZQAs6AsgBQCU+hxTUcZAdADICWAzgC4AeLgDs+APnQAbXn3QBedAG04AGhgrUKsgF0A3IyIBfZIaA=

тут не AddRange, а еще более эффективный метод.

C>Новый синтаксис для инициализации коллекций, который примерно такой же как старый, но другой.
C>Новый синтаксис для объявления переменных... аналогично.

Я тут внезапно после 20-летнего перерыва вынужден был взяться за С++
И с удивлением обнаружил аж три варианта инициализации переменных, int a = 5, int a(5), int a{5}.

Это я к чему... у C# еще есть куда расти!

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

_NN>>Новый синтаскис позволяет вызывать AddRange, что конечно более приемлимо чем вызов Add по отдельности.

C>Так что, есть источники? Потому что дизассемблер ничего подобного не показывает и похоже, что ты просто ляпнул глупость.

Потому что новый синтаксис не ограничивает тебя в выборе стратегий кроме разве что пары мест, и соответственно не мешает использовать самую оптимальную в каждом случае

Вот тебе AddRange:

Sharplab

public class Sample
{
    public List<int> M(IEnumerable<int> list) => [..list, 2];
}

//
// GENERATED CODE
//
public class Sample
{
    [NullableContext(1)]
    public List<int> M(IEnumerable<int> list)
    {
        List<int> list2 = new List<int>();
        list2.AddRange(list);
        list2.Add(2);
        return list2;
    }
}

Вот использование ToList:

Sharplab

public class Sample
{
    public List<int> M(IEnumerable<int> list) => [..list];
}

//
// GENERATED CODE
//
public class Sample
{
    [NullableContext(1)]
    public List<int> M(IEnumerable<int> list)
    {
        return Enumerable.ToList(list);
    }
}

·>А зачем всё это нужно? В каком коде требуется такая логика, что присвоение _каждого_ поля должно производить какие-то неявные действия? По-моему это какая-то архитектурная проблема, неясно зачем тут нужно что-то пихать в ЯП.

Случайно наткнулся на это сообщение, работая над похожей задачей (увы, на другом языке, где все ужасно).

Классика жанра: нужно реплицировать ВСЕ изменения какой-то иерархической структуры.

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

J>тут не AddRange, а еще более эффективный метод.

Присвоение поэлементно — явно не оптимальный вариант. Но вряд ли можно сделать лучше без изменений в CLR.

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

R> public List<int> M(IEnumerable<int> list) => [..list];

Превозмогая здравый смысл.

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

SD>Это я к чему... у C# еще есть куда расти!

Они стараются.

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

C>>Новый синтаксис для инициализации коллекций, который примерно такой же как старый, но другой.
C>>Новый синтаксис для объявления переменных... аналогично.

SD>Я тут внезапно после 20-летнего перерыва вынужден был взяться за С++
SD>И с удивлением обнаружил аж три варианта инициализации переменных, int a = 5, int a(5), int a{5}.

Это ещё не все варианты.
Инициализация в С++ действительно безумна. Лучше начинать с Си (перевод)
Инициализация в современном C++

Ну и классика:

Форест Гамп учит C++