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

_>Нет, писал и даже достаточно много, вообще считаю что WPF это лучшее что было для десктопа и всякие js и ts даже рядом не стояли.

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

_>Но на текущий момент это нишевая область. Кому нужен толстый клиент с его проблемами?

Всем, кто сейчас вынужден использовать сборки Electron'а, т.к. разработчики сначала сделали веб-версию, а потом таки решили завернуть в десктоп.

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

K>Ну, вот для GUI библиотеки будет генерироваться событие типа PropertyChanged, на него можно подписаться и делать что нужно, не меняя язык.

Еще само property надо написать, потом можно будет подключиться.

K>Только прикол такой "реактивности" в том, что в итоге появляется функция группового изменения данных и вместо одной финальной перерисовки бедное окно получает сотни команд на перерисовку после каждой изменённой записи.
K>И начинаются уже костыли, как бы эту "реактивность" временно отключить и пока Invalidate не вызывать

Тут 2 основных команды: Invalidate — только быстро помечает что состояние некорректное "dirty", Update — синхронизирует состояние.
Например, в WPF насколько знаю, в конце каждого обработчика системного события(то что в приложение приходит извне — мышь, клавиатура,...) автоматически вызывается Update (он обновляет только то что "dirty"), а во время обработки события только накапливаются флажки "dirty". Но при необходимости можно вручную вызвать Update и во время обработки события.
А в WindowsForms в этом деле полный хаос и неуправляемое поведение.

Еще один возможный подход: Есть только Update, и Suspend/Resume. После Suspend обновления замораживаются и только накапливаются флажки "dirty", а после Resume — сами действия по синхронизации.

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

.> ... спец-поддержку в ЯП... из пушки по воробьям.

property уже есть. Там где они почти не нужны, пишут так: int MyProperty{get;set;}
Но на практике многие используют и разные кастомные. Возможно, лучше это делать через макросы(SG), чтобы не жаловались, что слишком много фич в стандарте самого языка. Но эти SG хорошо бы еще допилить — то что есть это только начало.

Но непонятно: они они уже выкатили новую фичу с field (по ссылке выше). Она сокращает всего 1 cтрочку из 10-11. Это действительно "из пушек по воробьям".
Может они на будущее зарезервировали "field" и дальше будут не спеша, годами что-то еще прикручивать?

S_S>>Нужно везде где надо что-то инвалидировать или одним вызовом Invalidate(), или с кастомными действиями.
·>По-моему, это не самый продуктивный подход к UI.

Более продуктивный подход — это просто писать HTML/XAML и не заморачиваться. Реактивное поведение уже встроено в движок браузера. Но разработчикам движка пришлось заморачиваться.

S_S>>И инициализировать/деинициализировать при подключении объекта через проперти obj1.Prop = obj2; .
·>А через метод просто? obj1.connect(obj2)? Зачем тут проперти?

И еще GetConnectedObject(), и еще поле. Property это просто удобный синтаксический сахар для этих 3 деклараций Get,Set, field. Но сейчас это занимает 11 строк, а на SourceGenerators получается в 3 строчки.

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

S_S>Еще само property надо написать, потом можно будет подключиться.

Ну, свойство так и так заводить нужно.
Несколько лет существует Fody и как-то живут и жили без необходимости менять язык.
Есть, например, расширение для INotifyPropertyChanged: https://github.com/Fody/PropertyChanged
По аналогии можно и дополнительных обработчиков навесить.
Например, в Json.NET есть соглашение, что можно в классе добавить метод boolean ShouldSerializeXXX и он будет сериализатором вызываться для определения необходимости записи этого свойства в json.
Аналогичное можно для ViewModel добавить и реализовать автовызовы методов до изменений (XXXChanging), после (XXXChanged) и т.п.

S_S>Тут 2 основных команды: Invalidate — только быстро помечает что состояние некорректное "dirty", Update — синхронизирует состояние.

Ну, и в итоге потенциально будут артефакты, когда половину контролов пометил на перерисовку, а половина отрисовала кэшированные значения.
Самый прикол в том, что свойство меняется во ViewModel, а отреагировать на это должна View, которая в WPF с большой долей вероятности и так подписана на PropertyChanged и нет проблемы ещё добавить туда логики. Зато будет проблема, если во ViewModel будет принесён контрол (View) и будут напрямую дёргаться его методы.

В общем, по-моему это спорная хотелка, достаточно узкая и нет смысла для неё ничего в язык тащить, тем более, что технически и так можно решить кому нужно.

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

K>Ну, свойство так и так заводить нужно.
K>Несколько лет существует Fody и как-то живут и жили без необходимости менять язык.
K>Есть, например, расширение для INotifyPropertyChanged: https://github.com/Fody/PropertyChanged

Не знаю как там реализовано, если некоторым файлам почти 10 лет, может без SourceGenerators. Тогда сейчас уже это не актуально, лучше использовать SG.

S_S>>Тут 2 основных команды: Invalidate — только быстро помечает что состояние некорректное "dirty", Update — синхронизирует состояние.
K>Ну, и в итоге потенциально будут артефакты, когда половину контролов пометил на перерисовку, а половина отрисовала кэшированные значения.

Не будет артефактов. Вся перерисовка через Update, он сначала синхронизирует Layout (то что было LayoutInvalidated), потом отрисовывает графику(области которые оказались Invalidated). Глюки невозможны. И лишний раз не запустится ни Layout, ни Draw — то что уже синхронизировано, повторно делаться не будет.
Я говорю не про WPF, а про кастомную API, но в WPF вроде все так же.

K>В общем, по-моему это спорная хотелка, достаточно узкая и нет смысла для неё ничего в язык тащить, тем более, что технически и так можно решить кому нужно.

Да. Нужно просто расширить возможности SourceGenerators. Новые фичи уже стало почти не возможно добавлять в язык, чтобы никто не возмущался: "Зачем новые фичи, мы их не используем в своем проекте". Вот новая фича с "field" как раз непонятно для кого — не нужна ни для тех кто полный вариант property использует, ни для тех кто не использует.

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

S_S>Не знаю как там реализовано, если некоторым файлам почти 10 лет, может без SourceGenerators. Тогда сейчас уже это не актуально, лучше использовать SG.

По сути та же кодогенерация. IL пишут через через Emit.
Ну, и по ссылке же написано: "Starting with version 4 PropertyChanged.Fody ships with a C# code generator".

S_S>Не будет артефактов. Вся перерисовка через Update, он сначала синхронизирует Layout (то что было LayoutInvalidated), потом отрисовывает графику(области которые оказались Invalidated). Глюки невозможны. И лишний раз не запустится ни Layout, ни Draw — то что уже синхронизировано, повторно делаться не будет.
S_S>Я говорю не про WPF, а про кастомную API, но в WPF вроде все так же.

Ну, возьмём ObservableCollection. Допустим, биндим её к DataGrid, где у колонки автоширина выставлена.
Добавляем в цикле в коллекцию 10000 элементов. Получим занимательную анимацию как строчки появляются в гриде, ширина колонки меняется и всё это скачет, пока цикл не закончится.
Чем больше автоматической подгонки контролов под содержимое, тем веселее это всё может выглядеть.
Если у контрола отдельно поменяем ширину, потом высоту, то потенциально с этими всеми автоматическими вызовами получим, что сначала пользователь увидит перерисованный контрол с новой шириной, а следом он опять перерисуется под новую высоту.

S_S>Да. Нужно просто расширить возможности SourceGenerators. Новые фичи уже стало почти не возможно добавлять в язык, чтобы никто не возмущался: "Зачем новые фичи, мы их не используем в своем проекте". Вот новая фича с "field" как раз непонятно для кого — не нужна ни для тех кто полный вариант property использует, ни для тех кто не использует.

Как раз field — хорошая и полезная фича. Написал автосвойство, потом понадобилось добавить логику в setter и не нужно при этом создавать поле, прописывать обращения к нему, переживать, что кто-то может это поле напрямую вызывать/изменить, а не через свойство.

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

.>> ... спец-поддержку в ЯП... из пушки по воробьям.
S_S>property уже есть. Там где они почти не нужны, пишут так: int MyProperty{get;set;}
Насколько оно оправдано, тоже неясно. Такое чувство, что для VB-программистов модную штуку перетащили.

S_S>Но на практике многие используют и разные кастомные. Возможно, лучше это делать через макросы(SG), чтобы не жаловались, что слишком много фич в стандарте самого языка. Но эти SG хорошо бы еще допилить — то что есть это только начало.
По моему опыту полезнее кажется flent-builder+immutable структуры, и тут лучше работает кодогенерация.

S_S>Но непонятно: они они уже выкатили новую фичу с field (по ссылке выше). Она сокращает всего 1 cтрочку из 10-11. Это действительно "из пушек по воробьям".
S_S>Может они на будущее зарезервировали "field" и дальше будут не спеша, годами что-то еще прикручивать?
Слишком много магии.

S_S>·>По-моему, это не самый продуктивный подход к UI.
S_S>Более продуктивный подход — это просто писать HTML/XAML и не заморачиваться. Реактивное поведение уже встроено в движок браузера. Но разработчикам движка пришлось заморачиваться.
Дык HTML с кодом надо как-то стыковать, в любом случае.

S_S>>>И инициализировать/деинициализировать при подключении объекта через проперти obj1.Prop = obj2; .
S_S>·>А через метод просто? obj1.connect(obj2)? Зачем тут проперти?
S_S>И еще GetConnectedObject(), и еще поле.
Get зачем?

S_S> Property это просто удобный синтаксический сахар для этих 3 деклараций Get,Set, field. Но сейчас это занимает 11 строк, а на SourceGenerators получается в 3 строчки.
IDE этот сахар может рисовать-писать сама. Спорно, что требуется в самом яп.

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

·>Насколько оно оправдано, тоже неясно. Такое чувство, что для VB-программистов модную штуку перетащили.

Причём тут VB? Свойства — это отличная штука и сильно удобнее, чем отдельные get-/set- методы в C++ и Java.

·>Слишком много магии.

Никакой магии. Автосвойства так и так внутри генерируют поля для хранения данных, это просто сахар, который сокращает писанину.
Сейчас если автосвойство не подойдёт и нужно добавить логику в get/set, то придётся сначала добавить поле и прописать получение/запись значений в это поле.
Тут компилятор просто сможет работать с автосгенерированным полем и не нужно этих исходники засорять.

·>IDE этот сахар может рисовать-писать сама. Спорно, что требуется в самом яп.

И в итоге в исходниках простыни однострочных get и set методов, среди которых замучаешься полезное и нужное искать.
В той же Java люди обламываются всё это и писать и читать и прикручивают lombok для генерации, а не надеются на IDE.
Только там свойств нет, всё основано на полях, что порождает некоторые свои неприятные мелочи.

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

K>·>Насколько оно оправдано, тоже неясно. Такое чувство, что для VB-программистов модную штуку перетащили.
K>Причём тут VB? Свойства — это отличная штука и сильно удобнее, чем отдельные get-/set- методы в C++ и Java.
Отдельный set-get не настолько плох. Обычно такие простые тривиальные свойства составляют небольшую долю от объёма кода и лежат в отдельных model-классах в которые редко заглядываешь. Т.е. немного упрощают и так простую проблему. Ценность невелика. Зато лишняя когнитивная нагрузка.

K>·>Слишком много магии.
K>Никакой магии. Автосвойства так и так внутри генерируют поля для хранения данных, это просто сахар, который сокращает писанину.
K>Сейчас если автосвойство не подойдёт и нужно добавить логику в get/set, то придётся сначала добавить поле и прописать получение/запись значений в это поле.
K>Тут компилятор просто сможет работать с автосгенерированным полем и не нужно этих исходники засорять.
Вот эта неявная генерация — и есть магия. Если надо генерировать — так генерируй код явно.

K>·>IDE этот сахар может рисовать-писать сама. Спорно, что требуется в самом яп.
K>И в итоге в исходниках простыни однострочных get и set методов, среди которых замучаешься полезное и нужное искать.
Они коллапсятся. IDE неплохо умеет упрощать чтение простыней, притом неважно, поле это или просто однострочный метод. Всё выглядит одинаково.

K>В той же Java люди обламываются всё это и писать и читать и прикручивают lombok для генерации, а не надеются на IDE.
lombok в топку.

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

S_S>>Вот новая фича с "field" как раз непонятно для кого — не нужна ни для тех кто полный вариант property использует, ни для тех кто не использует.

K>Как раз field — хорошая и полезная фича. Написал автосвойство, потом понадобилось добавить логику в setter и не нужно при этом создавать поле, прописывать обращения к нему, переживать, что кто-то может это поле напрямую вызывать/изменить, а не через свойство.

Выше же говорилось, что это почти никогда не нужно. Непонятная "золотая середина" — т.е. фича нужна достаточно часто, чтобы выкинуть одну строчку; но недостаточно часто, чтобы выкинуть остальной мусор.

public Type PropertyName
{
    get;
    set
    {
        //field = value;
    }
}

Здесь зачем нужно писать "get; set{}" ? Что мешает так сделать? :

public Type PropertyName
{   
    //field = value;
}

Тогда бы на такую декларацию можно было бы навешивать свои генераторы. А в текущем виде удобнее их навешивать на обычные функции, чем на эту хрень.

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

S_S>Выше же говорилось, что это почти никогда не нужно.

Не нужно в языке что-то совсем узкое и заточенное под конкретные GUI или специфические сценарии.

S_S>Здесь зачем нужно писать "get; set{}" ?

Потому что бывает get; private set; или get; init;

S_S>Что мешает так сделать?

Потому что set это или init?
А get есть автоматический или его нет?
А если завтра мне нужно автоматический get заменить на специфический, то всю эту конструкцию править и добавлять get и set?
А добавь () и вот уже метод, да и на инициализатор похоже.

S_S>Тогда бы на такую декларацию можно было бы навешивать свои генераторы. А в текущем виде удобнее их навешивать на обычные функции, чем на эту хрень.

Не знаю как по кодогенераторам, как-то до них руки не доходили.
В плане ручного написания/чтения мизерная экономия и куча потенциальных проблем.

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

·>Отдельный set-get не настолько плох. Обычно такие простые тривиальные свойства составляют небольшую долю от объёма кода и лежат в отдельных model-классах в которые редко заглядываешь. Т.е. немного упрощают и так простую проблему. Ценность невелика. Зато лишняя когнитивная нагрузка.

На работу с данными отдельные методы плохо ложатся.
Имею ввиду всякие DTO для сериализации json, или маппинга строк БД.
Со свойствами в C# пишешь:

[JsonProperty("is_enabled")]
public boolean IsEnabled { get; set; }

и понимаешь, что значение свойства будет в json писаться/читаться в/из is_enabled. Всё в одном месте, коротко, понятно и удобно.
В Java без свойств это будет:

@JsonProperty("is_enabled")
boolean enabled;

public boolean isEnabled() {
  return this.enabled;
}

public void setEnabled(boolean value) {
  this.enabled = value;
}

В процессе коммитов от разных людей, разрешения конфликтов и т.п. это всё добро может разлететься в разные концы файла.
Сериализатору же либо придётся по соглашению именования методов ориентироваться и понимать, что при чтении из json поля is_enabled нужно вызвать метод setEnabled, т.к. вероятно он меняет нужное поле enabled.
Либо заставлять разработчика все методы помечать атрибутами и ещё больше писанины разводить и потом не забыть всё везде поправить при переименовании поля в json.
Либо напрямую некрасиво в приватные поля писать, что может привести к неприятным багам, если в set-методе всё же будет какая-то логика.
У меня вот как-то всех этих DTO/POCO/POJO достаточно ощутимая доля образуется и со свойствами в C# приятнее это всё писать, чем в Java с отдельными методами.
record'ы ещё завезли, но там свои нюансы хотя бы в плане поддержки разными библиотеками.

·>Вот эта неявная генерация — и есть магия. Если надо генерировать — так генерируй код явно.

Языки высокого уровня в принципе существуют из-за неявной генерации.
Вопрос в адекватности этой генерации и не слишком ли с ней легко выстрелить себе в ногу.
Те же автосвойства — это просто, понятно, никаких проблем с ними не вижу.
В секции set есть понятное по смыслу ключевое слово value, так же интуитивно туда ложится и field.

·>Они коллапсятся. IDE неплохо умеет упрощать чтение простыней, притом неважно, поле это или просто однострочный метод. Всё выглядит одинаково.

Мне такие IDE не попадались.

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

K>·>Отдельный set-get не настолько плох. Обычно такие простые тривиальные свойства составляют небольшую долю от объёма кода и лежат в отдельных model-классах в которые редко заглядываешь. Т.е. немного упрощают и так простую проблему. Ценность невелика. Зато лишняя когнитивная нагрузка.
K>На работу с данными отдельные методы плохо ложатся.
K>Имею ввиду всякие DTO для сериализации json, или маппинга строк БД.
json обычно не просто так json, а для обмена данными с другими системами, поэтому пишется какой-нибдуь swagger,avro,etc и по нему генерится код .Код маппинга строк генерится из схемы БД.

K>Со свойствами в C# пишешь:
А ты так не пиши. Пиши хотя бы так:

[JsonProperty("is_enabled")]
public boolean IsEnabled;

и собственно всё. И ЯП тебе явно запретит всякую дичь творить в data-only маппинговых классах, логику в сеттерах.

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

K>если в set-методе всё же будет какая-то логика.
Ибо нехрен.

K>У меня вот как-то всех этих DTO/POCO/POJO достаточно ощутимая доля образуется и со свойствами в C# приятнее это всё писать, чем в Java с отдельными методами.
Если уж очень надо, то такие методы умеет IDE писать за тебя.

K>record'ы ещё завезли, но там свои нюансы хотя бы в плане поддержки разными библиотеками.
они иммутабельные. Но можно кодогенерить билдеры для них и библиотеки прожуют.

K>·>Вот эта неявная генерация — и есть магия. Если надо генерировать — так генерируй код явно.
K>Языки высокого уровня в принципе существуют из-за неявной генерации.
K>Вопрос в адекватности этой генерации и не слишком ли с ней легко выстрелить себе в ногу.
K>Те же автосвойства — это просто, понятно, никаких проблем с ними не вижу.
K>В секции set есть понятное по смыслу ключевое слово value, так же интуитивно туда ложится и field.
Тут согласен, частично. Высокий уровень это не про то как нагенерить как можно больше, а выразить как можно больше с практической точки зрения как можно меньшим набором высокоуровневых понятий. И мне кажется более адектватным проводить черту чуть раньше. Уже есть методы, которые решают задачу изменения любых полей в любом порядке и ещё много чего. Поэтому зачем вводить ещё и свойства, которые как методы, но могут менять только одно поле. А потом ещё возможность кастомизировать менять одно поле и ещё вызывать некую нотификацию.

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

K>·>Они коллапсятся. IDE неплохо умеет упрощать чтение простыней, притом неважно, поле это или просто однострочный метод. Всё выглядит одинаково.
K>Мне такие IDE не попадались.
Вот здесь смотри картинку в вопросе, обрати внимание на номера строк. Тривиальные сеттеры-гетеры задетектились и заколлапсились.

Здравствуйте, Слава, Вы писали:
С>Это у них вместо DI-контейнера. А если вдруг ты напишешь GetBusinessObject для получения DataAccessObject, то оно скомпилируется, но упадёт в рантайме.
А почему здесь не используется

public AccountManagementBO()
        {
            AccountTypeConfigurationBo = BusinessObjectFactory.GetBusinessObject<AccountTypeConfigurationBO>();
            AccountManagementDao = DataAccessObjectFactory.GetDataAccessObject<AccountManagementDAO>();
            accesManagerDao = DataAccessObjectFactory.GetDataAccessObject<AccessManagerDao>());

?
Ребятки застряли в 2001 году и C# 1.0?

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

С>>Это у них вместо DI-контейнера. А если вдруг ты напишешь GetBusinessObject для получения DataAccessObject, то оно скомпилируется, но упадёт в рантайме.
S>А почему здесь не используется

S>Ребятки застряли в 2001 году и C# 1.0?

Они бы прошли дальше, но индийские усы не помещаются в дверной проём.

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

S>Ребятки застряли в 2001 году и C# 1.0?

Они в прошлом месяце кодили на каком-нибудь сраном жабаскрипте, а сейчас им сказали кодить на шарпе.
Потому что все должны уметь всё. (С)

Здравствуйте, Codealot, Вы писали:
C>Они в прошлом месяце кодили на каком-нибудь сраном жабаскрипте, а сейчас им сказали кодить на шарпе.
Больше похоже как раз на Java. В которой как раз "ненужных фич нет", поэтому код получается вот такой вот убогий — трудно пишется, плохо читается, получается ненадёжным.

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

S>Больше похоже как раз на Java. В которой как раз "ненужных фич нет", поэтому код получается вот такой вот убогий — трудно пишется, плохо читается, получается ненадёжным.

Из новичков практически никто ее не знает. Или жабаскрипт, или питон.

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

C>Из новичков практически никто ее не знает. Или жабаскрипт, или питон.
Такие приведения не характерны ни для JS, ни для Python. Зато вот в Java — направо и налево.

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

C>>Они в прошлом месяце кодили на каком-нибудь сраном жабаскрипте, а сейчас им сказали кодить на шарпе.
S>Больше похоже как раз на Java. В которой как раз "ненужных фич нет", поэтому код получается вот такой вот убогий — трудно пишется, плохо читается, получается ненадёжным.
В лучшем случае похоже на древние версии Java, времён когда ещё c# не изобрели.