Здравствуйте, Silver_S, Вы писали:
S_S>У них давно была попытка сделать переписывание кода через SG(или макросы). Но обломались — увидели, что есть проблемы с порядком применения нескольких макросов, если они используют побочные эффекты от работы предыдущих макросов. S_S>Теперь выглядит, что для них переписывание стало запретной темой, обходят ее далеко стороной.
Похоже, там начинаются серьёзные проблемы с производительностью. Но все эти запреты — это ненадолго. В C# уже воткнули все возможные разумные фичи практически из всех парадигм, кроме всякой экзотики. ООП был изначально. Из ФП перетянули всё вкусное. АОП тоже присутствует в некотором виде. Дальше расширяться некуда. Осталось только продвинутое метапрограммирование на уровне расширения компилятора и самого языка.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Codealot, Вы писали:
IT>>В фигурных скобках перечисляются объекты. А квадратные скобки используются для объявления массива/коллекции объектов. C> C>До тебя вообще не доходит, что программисты сами решают, как интерпертировать и использовать содержимое тех или иных скобок?
С чего бы? Судя по твоим заявлениям, непонимание базовых вещей приводит к обсолютно идиотской интерпретации. Ты случайно обычную грозу не интерпретируешь как проявление божественного вмешательства? Ты же как программист сам решаешь!
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
S_S>>Я бы решал добавлением новых фич в язык. Может даже введением нового ключевого слова "property", с расширяемым синтаксисом.
IT>Ничего не понял. Зачем вводить ключевое слово, которое вывглядит как обычный атрибут?
Мне нужно было бы только такое. По названию атрибута можно определить, что это property и без ключевых слов.
Но не жаловался бы, если бы ввели ключевое слово, если нашли бы какие-то сложности с парсингом или с читабельностью.
3 часто используемых варианта — описываются только тела setter с разной автоматизацией, остальное генерируется. Все пригодились бы одновременно:
//Тело вызовется после автоматического изменения field
[after_change] Type Name
{
//код
}
//вызовется после автоматической проверки: if(field==value) return;
[change] Type Name
{
//кодfield = value; //присваиваем вручную, зато можно вызвать код до изменения.
//код
}
//Для более гибких setter.
//Здесь ничего автоматически не делается. Все вручную: "if(AreSame(field,value)) return; ..."
[setter] Type Name
{
//код
}
//Можно для читабельности назвать [property_setter] Вместо [setter]
IT>Похоже, там начинаются серьёзные проблемы с производительностью.
Можно было бы захардкодить имена атрибутов: "[setter]" выглядит как пользовательский атрибут, а компилятор рассматривает как ключевое слово и сам генерирует property.
Тогда не было бы проблем с производительностью. Хотя вроде и так нет таких проблем.
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, _NN_, Вы писали:
_NN>>Правильно понимаю ?
C>Вроде да. Так почему они смогли реализовать это эффективно с квадратными скобками, но никак не могли с фигурными, которые использовались раньше?
С квадратными можно новые правила придумать.
А со старым синтаксисом менять правила это сломать рабочий код.
IT>>В фигурных скобках перечисляются объекты. А квадратные скобки используются для объявления массива/коллекции объектов.
C> C>До тебя вообще не доходит, что программисты сами решают, как интерпертировать и использовать содержимое тех или иных скобок?
Не все программисты одинаково полезны!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Osaka, Вы писали:
_>>А C# живой вообще? помнится мне когда он заходил после дельфи в 2007, когда был .NET 1.1 и потом 2.0 было конечно круто, у всех стояла винда и шарпы были на взлете. O>WPF ты стало быть пропустил.
Нет, писал и даже достаточно много, вообще считаю что WPF это лучшее что было для десктопа и всякие js и ts даже рядом не стояли.
Но на текущий момент это нишевая область. Кому нужен толстый клиент с его проблемами?
авто релизы, обновления, совместимости. Преимущества описывать не буду итак понятно, но условно какой массовый софт нужно писать на WPF?
_>Но на текущий момент это нишевая область. Кому нужен толстый клиент с его проблемами? _>авто релизы, обновления, совместимости. Преимущества описывать не буду итак понятно, но условно какой массовый софт нужно писать на WPF?
Заказное ПО, внутренняя автоматизация. Где скорость доделки нового функционала важнее устойчивости к тяжёлым условиям окружения.
Здравствуйте, IncremenTop, Вы писали:
IT>Здравствуйте, diez_p, Вы писали:
IT>Любой тырпрайз. Не говоря уже о том, что средний прогер на C# стоит дешевле, при этом экосистемы и тулинг продвинутые.
По сравнению с джавой комьюнити куда хуже, а уж msbuild + vs без решарпера еще то поделие.
Хотя язык и CLR правда хороши, до сих пор непонятно почему ms не научился исполнять джарники.
IT>>Любой тырпрайз. Не говоря уже о том, что средний прогер на C# стоит дешевле, при этом экосистемы и тулинг продвинутые. _>По сравнению с джавой комьюнити куда хуже, а уж msbuild + vs без решарпера еще то поделие. _>Хотя язык и CLR правда хороши, до сих пор непонятно почему ms не научился исполнять джарники.
Здравствуйте, IT, Вы писали:
IT>Дальше расширяться некуда. Осталось только продвинутое метапрограммирование на уровне расширения компилятора и самого языка.
Некоторые фичи могут хорошо выглядеть для 99% сценариев использования (с точки зрения чистоты языка), а для 1% случаев выглядеть коряво. Из-за этого 1%, разработчики никогда не включат их в язык, следя за чистотой языка. А когда важнее чистота кода в конкретном проекте, а не языка — для этих случаев помогают макросы.
Например, эти громоздкие property. Раз в несколько лет разработчики C# идут на небольшие уступки по сокращению копипасты. В C# 13 preview очередная мелкая уступка:
public Type PropertyName
{
get;
set
{
if (field == value) return;
field = value;
f(PropertyName);
}
}
If you use a helper method, you could write it as:
public Type PropertyName { get; set => Set(ref field, value, onChanged: () => f(PropertyName)); }
Слишком мелкое сокращение. В идеале это должно бы было прийти примерно к такому:
public implicit Type PropertyName
{
//OnChanged
}
Поэтому пока продолжу использование своих генераторов, хоть они тоже корявые, но более читабельные. Когда работа с проектом закончена, читать его больше не придется — проще скопипастить сгенерированный код на место этих макросов, чем постоянно читать длинную копипасту.
Здравствуйте, Silver_S, Вы писали:
S_S>Слишком мелкое сокращение. В идеале это должно бы было прийти примерно к такому:
А зачем всё это нужно? В каком коде требуется такая логика, что присвоение _каждого_ поля должно производить какие-то неявные действия? По-моему это какая-то архитектурная проблема, неясно зачем тут нужно что-то пихать в ЯП.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>А зачем всё это нужно? В каком коде требуется такая логика, что присвоение _каждого_ поля должно производить какие-то неявные действия? По-моему это какая-то архитектурная проблема, неясно зачем тут нужно что-то пихать в ЯП.
Например, все GUI библиотеки/приложения реактивные. Не инвалидируют же все вручную:
ctrl.Color = c;
ctrl.Invalidate();
Это не нужно для функционального кода, где только вычисления. Но там и property не нужны, хватит структур с полями.
Нужно везде где надо что-то инвалидировать или одним вызовом Invalidate(), или с кастомными действиями.
И инициализировать/деинициализировать при подключении объекта через проперти obj1.Prop = obj2; .
Там где реактивный функционал — когда нудная рутина по синхронизации состояний делается автоматически.
Здравствуйте, Silver_S, Вы писали:
S_S>·>А зачем всё это нужно? В каком коде требуется такая логика, что присвоение _каждого_ поля должно производить какие-то неявные действия? По-моему это какая-то архитектурная проблема, неясно зачем тут нужно что-то пихать в ЯП. S_S>Например, все GUI библиотеки/приложения реактивные. Не инвалидируют же все вручную:
Я не очень копенгаген в UI, но вроде когда последний раз писал небольшую SPA на ts с реактивным mithril, то там было наоборот — состояние как дерево, меняется, и вычисляются дельты, которые потом рендерятся.
Т.е. подход совсем другой и никакие специальные проперти не нужны. Поэтому как-то было бы странно, чтобы ради какого-то конкретного (притом, как я понимаю, не самого лучшего) подхода организации UI делать спец-поддержку в ЯП... из пушки по воробьям.
S_S>Это не нужно для функционального кода, где только вычисления. Но там и property не нужны, хватит структур с полями. S_S>Нужно везде где надо что-то инвалидировать или одним вызовом Invalidate(), или с кастомными действиями.
По-моему, это не самый продуктивный подход к UI.
S_S>И инициализировать/деинициализировать при подключении объекта через проперти obj1.Prop = obj2; .
А через метод просто? obj1.connect(obj2)? Зачем тут проперти?
S_S>Там где реактивный функционал — когда нудная рутина по синхронизации состояний делается автоматически.
Это, как раз, не реактивный подход, а как в каком-нибудь старинном Win32, ближе к ООП.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Silver_S, Вы писали:
S_S>Например, все GUI библиотеки/приложения реактивные. Не инвалидируют же все вручную:
Ну, вот для GUI библиотеки будет генерироваться событие типа PropertyChanged, на него можно подписаться и делать что нужно, не меняя язык.
Только прикол такой "реактивности" в том, что в итоге появляется функция группового изменения данных и вместо одной финальной перерисовки бедное окно получает сотни команд на перерисовку после каждой изменённой записи.
И начинаются уже костыли, как бы эту "реактивность" временно отключить и пока Invalidate не вызывать
Если нам не помогут, то мы тоже никого не пощадим.
