Новый синтаксис для инициализации коллекций, который примерно такой же как старый, но другой.
Новый синтаксис для объявления переменных... аналогично.
Фичи, которые в теории были полезны, но их реализовали так, что лучше бы вообще не делали. Тела методов в интерфейсах, например.
Тяп-ляп, заплатка на заплатку, никакой продуманности, никакой целостности дизайна.
Здравствуйте, Codealot, Вы писали:
C>Меня одного это уже начинает раздражать?
Переставляют кровати. Смысл околонулевой.
Фундамент языка — это целевые платформы (официально поддерживаемые) и реализация FFI. Т.е. чтобы проект можно было легально собрать на всех 6 платформах (Win, Lin, Mac, iOS, And, WASM) а так же использовать механизм для вызова библиотек из сторонних языков. Кроме FFI — другого механизма человечество не придумало. FFI — это аналог WebAPI только для десктопа — максимально быстрый и не требовательный к ресурсам. И уже когда это сделано — нужно смотреть насколько быстро все работает, насколько быстро запускается, размер бинарников и т.д.
Этого C# не умеет и не факт что скоро сумеет. Не беру в рассчет платные решения от remobjects.com, которые требуют затрат около $1000 в год на разраба.
Здравствуйте, Codealot, Вы писали:
C>Новый синтаксис для инициализации коллекций, который примерно такой же как старый, но другой. C>Новый синтаксис для объявления переменных... аналогично. C>Фичи, которые в теории были полезны, но их реализовали так, что лучше бы вообще не делали. Тела методов в интерфейсах, например. C>Тяп-ляп, заплатка на заплатку, никакой продуманности, никакой целостности дизайна.
C>Меня одного это уже начинает раздражать?
Да нет, как бы норм. Ни кто не заставляет использовать не очевидные фичи языка.
Здравствуйте, Qulac, Вы писали:
Q> Да нет, как бы норм. Ни кто не заставляет использовать не очевидные фичи языка.
Ну блин... А чужой код читать? Хотели сделать простой язык для маленьких девочек, а в результате, снова, получается чудо-юдо. Эта буква проклята, не иначе.
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, Qulac, Вы писали:
Q>> Да нет, как бы норм. Ни кто не заставляет использовать не очевидные фичи языка.
R>Ну блин... А чужой код читать? Хотели сделать простой язык для маленьких девочек, а в результате, снова, получается чудо-юдо. Эта буква проклята, не иначе.
Некоторые фичи я вот только на новой работе увидел. Тут ни чего лично против программистов ни кто не имеет, это просто бизнес, а сточки зрения бизнеса создателей языков — язык должен "развиваться" иначе про него все забудут и уйдут к конкурентам.
Здравствуйте, Privalov, Вы писали:
C>>Меня одного это уже начинает раздражать? P>Нет. Наверное потому, что я пишу на Фортране, используя Шарп. Привык.
а чужой код вообще не читаешь?
Кстати, оффтопом, я считал, что Python простой язык, но посмотрел, как параметры функций объявляются, и понял, что даже там всё не просто:
Здравствуйте, wl., Вы писали:
wl.>а чужой код вообще не читаешь?
Ну почему? Чужого кода я прочитал намного больше, чем сочинил своего. Но когда сочиняю, то на Фортране. И ничего не могу с этим поделать.
wl.>Кстати, оффтопом, я считал, что Python простой язык, но посмотрел, как параметры функций объявляются, и понял, что даже там всё не просто:
Я не знаток Питона. В том смысле, что ничего реального на нём не делал. Но кое с чем сталкивался. С этим тоже.
Здравствуйте, Codealot, Вы писали:
C>Фичи, которые в теории были полезны, но их реализовали так, что лучше бы вообще не делали. Тела методов в интерфейсах, например. C>Меня одного это уже начинает раздражать?
Может они там, этсамое, тикеты закрывают? Дейлики проводят.
Здравствуйте, Codealot, Вы писали:
C>Новый синтаксис для инициализации коллекций, который примерно такой же как старый, но другой.
Новый синтаксис позволяет создавать Span без аллокаций чего нельзя было бы сделать используя new Span<int>(new int{] {...}).
Так что как только у вас появятся в коде Span , там и порадуетесь за новую фичу.
C>Новый синтаксис для объявления переменных... аналогично.
А что за новый синтаксис ?
Это про targed-new или я что-то пропустил ?
List<int> a = new() { .. }
C>Фичи, которые в теории были полезны, но их реализовали так, что лучше бы вообще не делали. Тела методов в интерфейсах, например.аз
А как надо было бы ?
Вон в Java есть аналогичная возможность и вроде не жалуются.
C>Тяп-ляп, заплатка на заплатку, никакой продуманности, никакой целостности дизайна.
Ну нельзя сказать, что совсем нет.
Некоторые фичи обсуждают годами пока они придут в язык, чтобы было и полезно и без поломки существующего кода.
C>Меня одного это уже начинает раздражать?
Как раз необходимые фичи долго делают по мне.
Например не хватает in scoped.
Здравствуйте, Codealot, Вы писали:
C>Меня одного это уже начинает раздражать?
А можно вот прям кусочек кода, который тебя сильно сильно раздражает. А то "тяп-ляа, никакой продуманности" выглядит как откровенное нытьё. Ни у, конечно же, расскажи как бы ты сделал сам.
Если нам не помогут, то мы тоже никого не пощадим.
Q>Ни кто не заставляет использовать не очевидные фичи языка.
Как это не заставляет? А любимые работники руководства, код которых придётся сопровождать, когда они получат премию и уйдут на повышение?
Здравствуйте, IT, Вы писали:
IT>А можно вот прям кусочек кода, который тебя сильно сильно раздражает. А то "тяп-ляа, никакой продуманности" выглядит как откровенное нытьё.
Здравствуйте, _NN_, Вы писали:
_NN>Новый синтаксис позволяет создавать Span без аллокаций чего нельзя было бы сделать используя new Span<int>(new int{] {...}).
Расшифруй.
_NN>А как надо было бы ? _NN>Вон в Java есть аналогичная возможность и вроде не жалуются.
Здравствуйте, rFLY, Вы писали:
FLY>Что угодно будет плохим если не знать меры.
Как-то получилось, что именно с этой фичей меры не знают. Вероятно, играет свою роль, что решарпер все время предлагает повыкидывать имена типов.
В любом случае — им не следовало разрешать это делать, когда возникают неоднозначности в прочтении.
Здравствуйте, Codealot, Вы писали:
IT>>А можно вот прям кусочек кода, который тебя сильно сильно раздражает. А то "тяп-ляа, никакой продуманности" выглядит как откровенное нытьё. C>Особенно весело, когда там перегруженные методы и опциональные параметры. Вот и сиди чеши репу, пытаясь понять, что там за параметры.
Вывод типов он такой. Но тогда тебе нужно заклеймить практически все функциональные и полуфункциональные языки. Даже в C++ уже добавили auto. Ведь тебе по идее тогда должен раздражать и такой код:
var wtfIsThat = GetSomething()
Мне до типов как-то редко бывает дело. Но если надо, то подведи курсор к new (в твоём случае) или var и быстро узнаешь что к чему. Надеюсь ты не распечатки на бумаге читаешь? Т.е. если надо, а надо бывает в одном из двадцати случаев, то вообще не вопрос.
Что-то ещё?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Ведь тебе по идее тогда должен раздражать и такой код:
Нет, не должен. Там нет такого нагромождения неизвестных.
IT>Но если надо, то подведи курсор к new (в твоём случае) или var и быстро узнаешь что к чему. Надеюсь ты не распечатки на бумаге читаешь? Т.е. если надо, а надо бывает в одном из двадцати случаев, то вообще не вопрос.
Если в коде трудно разобраться без поддержки IDE, то этот код — полное говно. Фичи языка, которые такой код поощряют — тоже полное говно.
IT>Что-то ещё?
Вот, например, partial methods. Фича крайне сомнительной полезности, и в языке ей просто не место.
Здравствуйте, Codealot, Вы писали:
IT>>Ведь тебе по идее тогда должен раздражать и такой код: C>Нет, не должен. Там нет такого нагромождения неизвестных.
Ну давай я тебе сразу 5 var'ов напишу один за одним. Будет такое же нагромождение. Ещё раз, не нравится вывод типов — претензии к ФП.
C>Если в коде трудно разобраться без поддержки IDE, то этот код — полное говно. Фичи языка, которые такой код поощряют — тоже полное говно.
Какое наивное заблуждение. Современную производительность программиста обеспечивает не только выразительность языка, но даже в большей степени продвинутость IDE. Времена, когда можно было эффективно навигировать в нотепаде по всем 3-м файлам проекта и запомнить абсолютно все 200 функций и их сигнатуры стандартной библиотеки давно прошли. Лет 40 назад (хотя сигнатуры memcpy и cpymem я так и не запомнил, какая из них какая). Сейчас ни один современный язык не разрабатывается без учёта IDE. Прикинь! Даже C# был переписан через 10 лет его существования с нуля, чтобы облегчить его интеграцию в IDE, т.к. для этой самой интеграции требовалась команда большая, чем команда самого C#. И эта команда всё равно не успевала добавлять новые фичи языка в IDE.
F# вроде не самый плохой язык, но с убогой поддержкой IDE. Результат — на нём пишут только конченные фрики. Я знаю ещё один язык, который не стал популярным и уже приказал долго жить, главным образом благодаря тому, что поддержка IDE оказалась для его команды разработчиков непосильной задачей. Хотя сам язык я до сих пор считаю одним из лучших.
В общем, по такому твоему мнению об IDE складывается впечатление, что проекты сложнее 300-х строк ты никогда не видел. Бывает. Я тебя наверное огорчу, но сегодня IDE — это один из главных инструментов разработчика, не менее важный, чем сам язык. А дальше будет только хуже. Всякие Copilots уже подтягиваются и встраиваются они не в язык, прикинь!, а в IDE.
C>Вот, например, partial methods. Фича крайне сомнительной полезности, и в языке ей просто не место.
Эта фича предназначена и широко применяется совместно с генераторами кода.
Вот классический код для INotifyPropertyChanged, сгенерированный T4:
public partial class WeatherViewModel : INotifyPropertyChanged
{
private string? _location;
public string? Location
{
get { return _location; }
set
{
if (_location != value)
{
BeforeLocationChanged(value);
_location = value;
AfterLocationChanged();
OnLocationChanged();
}
}
}
partial void BeforeLocationChanged(string? newValue);
partial void AfterLocationChanged ();
}
Здравствуйте, Codealot, Вы писали:
C>Новый синтаксис для инициализации коллекций, который примерно такой же как старый, но другой. C>Новый синтаксис для объявления переменных... аналогично. C>Фичи, которые в теории были полезны, но их реализовали так, что лучше бы вообще не делали. Тела методов в интерфейсах, например. C>Тяп-ляп, заплатка на заплатку, никакой продуманности, никакой целостности дизайна.
C>Меня одного это уже начинает раздражать?
Так C# же с рождения такой — эдакая недо-Java, в которую тащут всё блестящее. На третий день Орлиный Глаз заметил, что у сарая нет одной стены.
Здравствуйте, IT, Вы писали:
IT>Ну давай я тебе сразу 5 var'ов напишу один за одним. Будет такое же нагромождение. Ещё раз, не нравится вывод типов — претензии к ФП.
Нет, такой же многократно вложенной хрени не будет.
IT>В общем, по такому твоему мнению об IDE складывается впечатление
Кхм, это всё ты просто из пальца высосал.
IDE помогает, но код, который без нее даже разобрать нельзя — говно.
IT>Как по мне, так волне себе качественное решение. А как бы ты сам решал подобную задачу? Какими-нибудь виртуальными методами?
Один из вариантов. Только не говори, что это будет жжжутко медленно.
Здравствуйте, vsb, Вы писали:
vsb>Так C# же с рождения такой — эдакая недо-Java, в которую тащут всё блестящее.
Раньше до такого все же не доходило. Сейчас смотрю на список новых фич и периодически чешу репу — а что, это кому-то нужно, кроме горстки людей на весь мир? И эта горстка, по чистому совпадению, в основном работает в C# team?
Здравствуйте, Codealot, Вы писали:
vsb>>Так C# же с рождения такой — эдакая недо-Java, в которую тащут всё блестящее.
C>Раньше до такого все же не доходило. Сейчас смотрю на список новых фич и периодически чешу репу — а что, это кому-то нужно, кроме горстки людей на весь мир? И эта горстка, по чистому совпадению, в основном работает в C# team?
Ну видимо у каждого своя граница. Я как ни посмотрю на очередной список фич в C#, так у меня это впечатленеи и складывается. Вот взять C# 3.
LINQ — недо-SQL, недо-ORM в языке. Не нужно.
Customer c = new Customer { Name = "John" };
вместо двух строчек. Не нужно.
MyList list = new MyList { 1, 2 };
вместо обычного метода List.of(1, 2). Не нужно.
Ну про var уже говорили, по-мне не нужная фича, но весь мир сошёл с ума, чёрт с ним.
var x = new { FirstName = "John", LastName = "Doe" };
Анонимный тип. Не нужно.
Лямбды. Ок, нужно.
Дальше мотать устал. В общем примерно так — на 1 нужную фичу 10 ненужных. И это 3 версия, 17 лет назад выпущенная. Что там с тех времён насували, страшно представить.
Вот в Java хорошо. Никаких новых фич. switch 10 лет расширяют тривиальными улучшениями (по-мне тоже не нужно, но видимо у дизайнера джавы детская травма, связанная с ADT, поэтому он их потихоньку и тянет в язык). А так все улучшения тупо на уровне JVM, то GC новый придумают, то вот потоки зелёные делают, в стандартную библиотеку какие-то методы новые потихоньку добавляют, по сути последнее фундаментальное обновление языка было в 5 версии 20 лет назад.
Здравствуйте, Codealot, Вы писали:
C>Новый синтаксис для инициализации коллекций, который примерно такой же как старый, но другой. C>Новый синтаксис для объявления переменных... аналогично. C>Фичи, которые в теории были полезны, но их реализовали так, что лучше бы вообще не делали. Тела методов в интерфейсах, например. C>Тяп-ляп, заплатка на заплатку, никакой продуманности, никакой целостности дизайна.
C>Меня одного это уже начинает раздражать?
А C# живой вообще? помнится мне когда он заходил после дельфи в 2007, когда был .NET 1.1 и потом 2.0 было конечно круто, у всех стояла винда и шарпы были на взлете.
Потом UI постепенно начал уходить в веб и мобилку, сервера на *nix. Шарпы и .NET стал совсем не нужен, хотя в плане языка мне очень нравится.
Далее конечно выпустили .NET Core и официально стали саппортить *nix, но на линухе альтернативы просто вагон и маленькая тележка.
Тот кому надо быстро наговнятькать — возьмет питон или php, то что будет тормозить на питоне перепишет на го. Тот кому нужен ынтерпрайз возьмет java/kotlin где либов просто ворох всяких разных и коммьюнити очень большое.
Тот кому надо написать что-то спейифическое возьмет С++/С/Rust/Go где тут место шарпам? Разве что только альтернатива джава/котлин?
Здравствуйте, Codealot, Вы писали:
IT>>Ну давай я тебе сразу 5 var'ов напишу один за одним. Будет такое же нагромождение. Ещё раз, не нравится вывод типов — претензии к ФП. C>Нет, такой же многократно вложенной хрени не будет.
Будет многократно не вложенная хрень.
IT>>В общем, по такому твоему мнению об IDE складывается впечатление C>Кхм, это всё ты просто из пальца высосал.
В этом топике ты единственный сосальщик. Высосать не понятно из чего проблемы, которых не существует нужно уметь.
C>IDE помогает, но код, который без нее даже разобрать нельзя — говно.
Да я уже понял. 300 строк — максимальный размер твоего проекта.
IT>>Как по мне, так волне себе качественное решение. А как бы ты сам решал подобную задачу? Какими-нибудь виртуальными методами? C>Один из вариантов. Только не говори, что это будет жжжутко медленно.
Это решение, при наличии качественного, как раз и можно назвать говном. Всё как ты любишь.
Больше у тебя, как я понимаю, никаких претензий к C#. Или ещё чего-нибудь высосешь?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Будет многократно не вложенная хрень.
Не разводи демагогию. В случае с var, тип однозначно определяется результатом метода. В случае с этой фичей, что там происходит на фоне десятка перегруженных методов с разными аргументами — сам черт ногу сломит.
IT>В этом топике ты единственный сосальщик. Высосать не понятно из чего проблемы, которых не существует нужно уметь. IT>Да я уже понял. 300 строк — максимальный размер твоего проекта.
Здравствуйте, rFLY, Вы писали:
FLY>AddItem(new("foo", 123, false));
Это осложняет жизнь разработчикам библиотек и пользователям. Допустим, есть CoolLib v1.0 с таким методом void AddItem(SimpleItem item). Уже становится невозможно просто добавить void AddItem(SpecialItem item) в CoolLib v1.1 не сломав совместимость.
Т.е. overloading стал неюзабельным.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Это осложняет жизнь разработчикам библиотек и пользователям. Допустим, есть CoolLib v1.0 с таким методом void AddItem(SimpleItem item). Уже становится невозможно просто добавить void AddItem(SpecialItem item) в CoolLib v1.1 не сломав совместимость. ·>Т.е. overloading стал неюзабельным.
А как компилятор это пропускает или в AddItem принимает object без конкретного типа?
Здравствуйте, rFLY, Вы писали:
FLY>Здравствуйте, ·, Вы писали:
FLY>·>Это осложняет жизнь разработчикам библиотек и пользователям. Допустим, есть CoolLib v1.0 с таким методом void AddItem(SimpleItem item). Уже становится невозможно просто добавить void AddItem(SpecialItem item) в CoolLib v1.1 не сломав совместимость. FLY>·>Т.е. overloading стал неюзабельным. FLY>А как компилятор это пропускает или в AddItem принимает object без конкретного типа?
Я не понял вопрос. Повторюсь:
CoolLib v1.0:
Здравствуйте, ·, Вы писали:
·>весь юзерский код при апдейте v1.0 -> v1.1 перестаёт компиляться с ambiguity.
В библиотеку было добавлено новое объявление метода по этому и ошибки с неоднозначностью? Тут, не уверен — не обгоняй, чего еще можно сказать.
_>А C# живой вообще? помнится мне когда он заходил после дельфи в 2007, когда был .NET 1.1 и потом 2.0 было конечно круто, у всех стояла винда и шарпы были на взлете.
WPF ты стало быть пропустил. _>Потом UI постепенно начал уходить в веб и мобилку, сервера на *nix. Шарпы и .NET стал совсем не нужен, хотя в плане языка мне очень нравится.
Никто никуда не "начал уходить", это физически невозможно в большинстве задач для стационарных машин (ну нет у смердфона большого экрана и клавиатуры с мышью, и ничего созидательного кроме игрушек и обмана на деньги туда не влазит). _>Тот кому надо быстро наговнятькать — возьмет питон или php, то что будет тормозить на питоне перепишет на го. Тот кому нужен ынтерпрайз возьмет java/kotlin где либов просто ворох всяких разных и коммьюнити очень большое. _>Тот кому надо написать что-то спейифическое возьмет С++/С/Rust/Go где тут место шарпам? Разве что только альтернатива джава/котлин?
Т. е. кому надо "наговнятькать", тот отвлечётся на несколько лет выучить всё это?
А кому надо сделать рентабельно и качественно, и потом поддерживать, и он уже знает C#, зачем ему что-то другое?
Здравствуйте, rFLY, Вы писали:
FLY>·>весь юзерский код при апдейте v1.0 -> v1.1 перестаёт компиляться с ambiguity. FLY>В библиотеку было добавлено новое объявление метода по этому и ошибки с неоднозначностью?
Да.
FLY>Тут, не уверен — не обгоняй, чего еще можно сказать.
Так я хочу сказать, о том как добавление абсолютно бесполезного сахара ведёт к поломке действительно удобной фичи оверлоада методов. Сабж, однако.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, vsb, Вы писали:
vsb>>Так C# же с рождения такой — эдакая недо-Java, в которую тащут всё блестящее.
C>Раньше до такого все же не доходило. Сейчас смотрю на список новых фич и периодически чешу репу — а что, это кому-то нужно, кроме горстки людей на весь мир? И эта горстка, по чистому совпадению, в основном работает в C# team?
ну так есть команда, ей же надо что-то делать,чтобы народ видел фичи новые идут.
Здравствуйте, vsb, Вы писали:
vsb>LINQ — недо-SQL, недо-ORM в языке. Не нужно.
Одна из лучших фич языка. Удобство работы с объектами гигантское.
Может и как замена SQL — но это не главное его использование.
vsb>вместо двух строчек. Не нужно.
Нужно. Отличная читаемость кода.
vsb>Вот в Java хорошо. Никаких новых фич. switch 10 лет расширяют тривиальными улучшениями
Да-да, и дженерики не нужны. Когда выбирал на какой язык перейти — именно из-за этого послал Джаву. Смотрелась говном мамонта еще в конце 00-х.
vsb> то вот потоки зелёные делают, в стандартную библиотеку какие-то методы новые потихоньку добавляют
Трудноюзабельное говно, на которое жалуются джависты, вкусившие сшарп.
_>Тот кому надо быстро наговнятькать — возьмет питон или php, то что будет тормозить на питоне перепишет на го. Тот кому нужен ынтерпрайз возьмет java/kotlin где либов просто ворох всяких разных и коммьюнити очень большое.
Java просто убога по сравнению с C# и отставала от него на лет 10. Котлин — как попытка как раз симбиоза между джава и шарпами.
_> Разве что только альтернатива джава/котлин?
Любой тырпрайз. Не говоря уже о том, что средний прогер на C# стоит дешевле, при этом экосистемы и тулинг продвинутые.
C>Особенно весело, когда там перегруженные методы и опциональные параметры. Вот и сиди чеши репу, пытаясь понять, что там за параметры.
А мне вот немножко непонятно, почему ещё никто не сделал инструмент (назовём его раззалупливатель), который анализирует код и приводит написанное таким образом в явную форму. Прямо вот в просмотрщике.
Здравствуйте, vsb, Вы писали:
vsb>Вот в Java хорошо. Никаких новых фич. switch 10 лет расширяют тривиальными улучшениями (по-мне тоже не нужно, но видимо у дизайнера джавы детская травма, связанная с ADT, поэтому он их потихоньку и тянет в язык). А так все улучшения тупо на уровне JVM, то GC новый придумают, то вот потоки зелёные делают, в стандартную библиотеку какие-то методы новые потихоньку добавляют, по сути последнее фундаментальное обновление языка было в 5 версии 20 лет назад.
Может я чего не знаю, но меня удивляет, что для явы есть коммерческие GC, более высокопроизводительные, чем стандартный. А для .CLR нету.
Это у них вместо DI-контейнера. А если вдруг ты напишешь GetBusinessObject для получения DataAccessObject, то оно скомпилируется, но упадёт в рантайме.
Зря этим людям IDE дали, по-моему. Без IDE oни бы столько кубокилометров мусора не понаписали.
Здравствуйте, ·, Вы писали:
FLY>>AddItem(new("foo", 123, false)); ·>Это осложняет жизнь разработчикам библиотек и пользователям. Допустим, есть CoolLib v1.0 с таким методом void AddItem(SimpleItem item). Уже становится невозможно просто добавить void AddItem(SpecialItem item) в CoolLib v1.1 не сломав совместимость. ·>Т.е. overloading стал неюзабельным.
Вот правильно в Rust этот overloading вообще запретили.
Здравствуйте, e.thrash, Вы писали:
ET>ну так есть команда, ей же надо что-то делать,чтобы народ видел фичи новые идут.
Могли бы, например, добавить объявление классов прямо внутри метода.
Зачем это нужно: иногда надо внутри одного класса передавать не-примитивные данные между методами. То есть, не Task<int>, а Task<XXX>, где у XXX имеется несколько именованных полей. Да, можно написать Task<(string, int, string)>, можно ещё чего-нибудь такое же изобрести. Но внутри метода можно написать:
var r = new
{
Name = "",
Amount = 148.8,
IsVerified = false
}
А вот return r уже нельзя. Хорошо бы иметь возможность написать что-то в духе var r = newclass classname(public|internal|private).
Здравствуйте, e.thrash, Вы писали:
IT>>Да я уже понял. 300 строк — максимальный размер твоего проекта. ET>вещи которые автор написал усложняют чтение кода.
Тут явно есть некоторая разница. Не находишь?
ET>Зависеть от IDE так себе идея, часто они глючат, не говоря уже про подсказки в них.
Это не идея. Это правда жизни. У меня один товарищ пользует Ryder, потому что он очень шустро работает с проектом в 700k строк и в там очень шутсрая навигация. Но в тоже самое время он пользует студию, потому что там лучше отладчик и поддержка WPF. Варианта notepad из-за глюков райдера и студии он не рассматривает.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Слава, Вы писали:
IT>>Даже C# был переписан через 10 лет его существования с нуля С>Однако ж. Я о таком не знал.
Пообщайся с нашими MVP-шниками: AVK, Sinclair, golumn, IB. Они тебе многое расскажут.
С>А чего они тогда его нормальным не сделали, если уж с нуля переписали?
Потому что люди решают те задачи, до которых они доросли на тот момент, когда перед ними встают конкретные и понятные им проблемы. Если ты не понимаешь будущих проблем и не можешь их предсказать, то для тебя они не существуют и закладки для их решения в архитектуру не закладываются. А потом уже поздно. К сожалению архитектура — это то, что в будущем практически невозможно поменять.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Слава, Вы писали:
С>Это у них вместо DI-контейнера. С>Зря этим людям IDE дали, по-моему. Без IDE oни бы столько кубокилометров мусора не понаписали.
IoС контейнер — это очень злобное решение само по себе. Корень зла здесь в том, что программист отказывается от тех проверок, которые компилятор (внимение! компилятор, а не IDE) выполняет автоматически. IDE тут вообще ни при чём. Наоборот, продвинутые IDE пытаются в таких ситуациях подсказывать и выполнять работу компилятора, но это либо у них не очень получается, либо тупо игнорируется. Ведь некоторые программисты умнее и компилятора и IDE, поэтому пихают IoC контейнеры везде, где только можно только потому, что могут.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
С>>Это у них вместо DI-контейнера. С>>Зря этим людям IDE дали, по-моему. Без IDE oни бы столько кубокилометров мусора не понаписали.
IT>IoС контейнер — это очень злобное решение само по себе. Корень зла здесь в том, что программист отказывается от тех проверок, которые компилятор (внимение! компилятор, а не IDE) выполняет автоматически. IDE тут вообще ни при чём. Наоборот, продвинутые IDE пытаются в таких ситуациях подсказывать и выполнять работу компилятора, но это либо у них не очень получается, либо тупо игнорируется. Ведь некоторые программисты умнее и компилятора и IDE, поэтому пихают IoC контейнеры везде, где только можно только потому, что могут.
Я не совсем понимаю ваши возражения. Как раз в приведённом мной участке кода проверка компилятора отсутствует. В случае IoC тут на вход прилетали бы нужные интерфейсы, безо всякого приведения типов. Как раз с контролем компилятора.
И работоспособность всего дерева зависимостей в IoC можно проверить одним тестом.
Наконец, в случае наличия тут IoC, этот код было бы гораздо проще улучшать. Например, сейчас там сервис(1) при отработке запроса обращается к самому себе, но в другом экземпляре(2), через WCF, оттуда запрос идёт по REST в ещё некоторые сервисы, и по MQ в неизвестные сервисы, и из них уже запрос, его часть, может прилететь обратно в(1), через MQ. Ко всему этому счастью надо бы добавить correlation id, чтобы понимать, где что падает (а оно падает). Для этого в IoC можно было бы просто добавить один интерфейс на уровне scope, для каждого отдельного запроса, и прозрачно пробросить этот id до самых вызовов внешних сервисов. А в имеющемся рукопашном коде такого сделать просто нельзя, только вручную. Для ручного прокидывания придётся править сигнатуры примерно 5000 методов.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, e.thrash, Вы писали:
IT>>>Да я уже понял. 300 строк — максимальный размер твоего проекта. ET>>вещи которые автор написал усложняют чтение кода.
IT>Те же самые вещи:
IT>
тут лаконичнее, да, но ведь есть var если надо короче писать.
ET>>Зависеть от IDE так себе идея, часто они глючат, не говоря уже про подсказки в них.
IT>Это не идея. Это правда жизни. У меня один товарищ пользует Ryder, потому что он очень шустро работает с проектом в 700k строк и в там очень шутсрая навигация. Но в тоже самое время он пользует студию, потому что там лучше отладчик и поддержка WPF. Варианта notepad из-за глюков райдера и студии он не рассматривает.
тут соглашусь, смотреть по задачам. у меня вот райдер в типе отображения проекта Solution не показывает папку с sql миграциями. Приходится переключаться в FileSystem
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, _NN_, Вы писали:
_NN>>Новый синтаксис позволяет создавать Span без аллокаций чего нельзя было бы сделать используя new Span<int>(new int{] {...}).
C>Расшифруй.
Проблема в этой записи в том, что она требует создание массива а потом только можно из него создать Span.
Получаем выделение памяти когда хотелось бы без него.
Решить можно через stackalloc , но тогда у нас код будет сильно разниться для разных случаев.
Новый синтаксис позволяет записывая одинаковый код получить лучшую производительность.
Здравствуйте, Слава, Вы писали:
vsb>>Вот в Java хорошо. Никаких новых фич. switch 10 лет расширяют тривиальными улучшениями (по-мне тоже не нужно, но видимо у дизайнера джавы детская травма, связанная с ADT, поэтому он их потихоньку и тянет в язык). А так все улучшения тупо на уровне JVM, то GC новый придумают, то вот потоки зелёные делают, в стандартную библиотеку какие-то методы новые потихоньку добавляют, по сути последнее фундаментальное обновление языка было в 5 версии 20 лет назад. С>Может я чего не знаю, но меня удивляет, что для явы есть коммерческие GC, более высокопроизводительные, чем стандартный.
Нет такого абстрактного самого высокопроизовдительного. Есть заточенные под определённые условия использования.
С>А для .CLR нету.
Потому что серьёзный софт для него не пишут, а для типичных ниш вроде веба или гуи, где на производительность пофиг — это нафиг не впёрлось.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Слава, Вы писали:
FLY>>>AddItem(new("foo", 123, false)); С>·>Это осложняет жизнь разработчикам библиотек и пользователям. Допустим, есть CoolLib v1.0 с таким методом void AddItem(SimpleItem item). Уже становится невозможно просто добавить void AddItem(SpecialItem item) в CoolLib v1.1 не сломав совместимость. С>·>Т.е. overloading стал неюзабельным. С>Вот правильно в Rust этот overloading вообще запретили.
Ты решил посравнивать тёплое с мягким? В Rust и new запретили, зато есть traits, макросы и ещё чего я не знаю для замены overloading.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, wl., Вы писали:
wl.>а чужой код вообще не читаешь? wl.>Кстати, оффтопом, я считал, что Python простой язык, но посмотрел, как параметры функций объявляются, и понял, что даже там всё не просто:
wl.>def func(*args): wl.>def func(**kwargs): wl.>def func(a, b, /, c): wl.>def func(a, b=5):
Здравствуйте, Константин Б., Вы писали:
КБ>Здравствуйте, wl., Вы писали:
wl.>>а чужой код вообще не читаешь? wl.>>Кстати, оффтопом, я считал, что Python простой язык, но посмотрел, как параметры функций объявляются, и понял, что даже там всё не просто:
wl.>>def func(*args): wl.>>def func(**kwargs): wl.>>def func(a, b, /, c): wl.>>def func(a, b=5):
КБ>Серъезно? Вот это вот сложно?
кроме 4-го варианта, который встречается в том же C++, понять, что означает третий вариант без подсказки из зала (от chatgpt) сходу не получилось
Здравствуйте, wl., Вы писали:
wl.>Здравствуйте, Константин Б., Вы писали:
КБ>>Здравствуйте, wl., Вы писали:
wl.>>>а чужой код вообще не читаешь? wl.>>>Кстати, оффтопом, я считал, что Python простой язык, но посмотрел, как параметры функций объявляются, и понял, что даже там всё не просто:
wl.>>>def func(*args): wl.>>>def func(**kwargs): wl.>>>def func(a, b, /, c): wl.>>>def func(a, b=5):
КБ>>Серъезно? Вот это вот сложно?
wl.>кроме 4-го варианта, который встречается в том же C++, понять, что означает третий вариант без подсказки из зала (от chatgpt) сходу не получилось
Я правильно понимаю что вы руководствуетесь логикой "знаю c++ — значит знаю на 90% все остальные языки"? У меня для вас плохие новости.
Здравствуйте, Константин Б., Вы писали:
КБ>Я правильно понимаю что вы руководствуетесь логикой "знаю c++ — значит знаю на 90% все остальные языки"? У меня для вас плохие новости.
насколько плохие? посмотрел тут на flutter+dart — ба! знакомые всё люди
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, Codealot, Вы писали:
vsb>>>Так C# же с рождения такой — эдакая недо-Java, в которую тащут всё блестящее.
C>>Раньше до такого все же не доходило. Сейчас смотрю на список новых фич и периодически чешу репу — а что, это кому-то нужно, кроме горстки людей на весь мир? И эта горстка, по чистому совпадению, в основном работает в C# team?
vsb>Ну видимо у каждого своя граница. Я как ни посмотрю на очередной список фич в C#, так у меня это впечатленеи и складывается. Вот взять C# 3.
vsb>LINQ — недо-SQL, недо-ORM в языке. Не нужно.
У тебя чрезвычайно ограниченный взгляд на LINQ в частности и на Expression Trees в целом и на их область применения. Скорее всего, ты просто не работал с этими штуками достаточно серёьзно и не в курсе, чего они могут.
Здравствуйте, Слава, Вы писали:
С>А вот return r уже нельзя. Хорошо бы иметь возможность написать что-то в духе var r = newclass classname(public|internal|private).
Теперь для решения этой задачи есть tuple. Правда, определения полей придется копи-пастить. Еще можно использовать record, но тогда придется все же объявить его на верхнем уровне в явном виде. Хотя и с меньшим количеством бойлерплейта, чем для обычного типа.
Вот так для решения одной задачи у нас есть уже три разных средства, и каждое — по своему кривое.
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, _NN_, Вы писали:
_NN>>Новый синтаксис позволяет записывая одинаковый код получить лучшую производительность.
C>Это результат не синтаксиса, а его реализации. Ничто не мешало просто улучшить старую реализацию.
Вопрос, что вы имеете ввиду под старой реализацией ?
Здравствуйте, IT, Вы писали:
IT>Вот классический код для INotifyPropertyChanged, сгенерированный T4: ... IT>Как по мне, так волне себе качественное решение. А как бы ты сам решал подобную задачу? Какими-нибудь виртуальными методами?
Я бы решал добавлением новых фич в язык. Может даже введением нового ключевого слова "property", с расширяемым синтаксисом. Универсального и лаконичного формата не придумали. Поэтому надо разрешить самодельщину, ключевое слово "property" нужно было бы для сохранения читабельности, когда большой зоопарк форматов.
using PropertyChanged.SourceGenerator;
public partial class MyViewModel
{
[Notify] private string _lastName;
public string FullName => $"Dr. {LastName}";
}
partial class MyViewModel : INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged;
public string LastName
{
get => _lastName;
set
{
if (!EqualityComparer<string>.Default.Equals(_lastName, value))
{
_lastName = value;
OnPropertyChanged(EventArgsCache.LastName);
OnPropertyChanged(EventArgsCache.FullName);
}
}
}
protected virtual void OnPropertyChanged(PropertyChangedEventArgs args)
{
PropertyChanged?.Invoke(args);
}
}
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, _NN_, Вы писали:
_NN>>И здесь нельзя менять семантику потому как на ней завязано достаточно много кода.
C>Почему, собственно?
Уточните вопрос.
Почему нельзя из
new Collection { 1, 2, 3 }
Генерировать
Collection t = new();
t.AddRange(new[] { 1, 2, 3 });
Было бы лучше, если бы было нормальное имя самого проперти, а не поля. Это же не редко используемая мегафича, а синтаксический сахар для очень массового применения.
S> Здесь проблема, что SG не может модифицировать существующий код
У них давно была попытка сделать переписывание кода через SG(или макросы). Но обломались — увидели, что есть проблемы с порядком применения нескольких макросов, если они используют побочные эффекты от работы предыдущих макросов.
Теперь выглядит, что для них переписывание стало запретной темой, обходят ее далеко стороной.
Я пытался там предложить вариант жульничества — простую в реализации имитацию переписывания без побочных эффектов(не покушаясь на запретную тему): Dummy declarations for Source Generators #7698
Но то ли их не заинтересовала тема, то ли не получилось внятно изложить.
Хотя для такого способа описания пропертей, не помешало бы еще разрешить такой синтаксис только для генераторов:
[MyPropertyGenerator] string? Location
{
_location = value; //Или лучше "field = value;" - в C# уже обсуждают ключевое слово "field"
}
Если почти закончились фичи для новых версий C#. Решили бы проблемы с лаконичностью пропертей. Тем более есть способы решения с минимальным изменением языка или компилятора.
Здравствуйте, Silver_S, Вы писали:
IT>>Вот классический код для INotifyPropertyChanged, сгенерированный T4: ... IT>>Как по мне, так волне себе качественное решение. А как бы ты сам решал подобную задачу? Какими-нибудь виртуальными методами?
S_S>Я бы решал добавлением новых фич в язык. Может даже введением нового ключевого слова "property", с расширяемым синтаксисом.
Ничего не понял. Зачем вводить ключевое слово, которое вывглядит как обычный атрибут?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Codealot, Вы писали:
C>Вроде да. Так почему они смогли реализовать это эффективно с квадратными скобками, но никак не могли с фигурными, которые использовались раньше?
Потому что ты как обычно не понимаешь сути. В фигурных скобках перечисляются объекты. А квадратные скобки используются для объявления массива/коллекции объектов.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, 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 не вызывать
Здравствуйте, 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 неплохо умеет упрощать чтение простыней, притом неважно, поле это или просто однострочный метод. Всё выглядит одинаково.
Здравствуйте, 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, то оно скомпилируется, но упадёт в рантайме.
А почему здесь не используется
Здравствуйте, Sinclair, Вы писали:
С>>Это у них вместо DI-контейнера. А если вдруг ты напишешь GetBusinessObject для получения DataAccessObject, то оно скомпилируется, но упадёт в рантайме. S>А почему здесь не используется
S>Ребятки застряли в 2001 году и C# 1.0?
Они бы прошли дальше, но индийские усы не помещаются в дверной проём.
Здравствуйте, Codealot, Вы писали: C>Они в прошлом месяце кодили на каком-нибудь сраном жабаскрипте, а сейчас им сказали кодить на шарпе.
Больше похоже как раз на Java. В которой как раз "ненужных фич нет", поэтому код получается вот такой вот убогий — трудно пишется, плохо читается, получается ненадёжным.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Больше похоже как раз на Java. В которой как раз "ненужных фич нет", поэтому код получается вот такой вот убогий — трудно пишется, плохо читается, получается ненадёжным.
Из новичков практически никто ее не знает. Или жабаскрипт, или питон.
Здравствуйте, Codealot, Вы писали:
C>Из новичков практически никто ее не знает. Или жабаскрипт, или питон.
Такие приведения не характерны ни для JS, ни для Python. Зато вот в Java — направо и налево.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
C>>Они в прошлом месяце кодили на каком-нибудь сраном жабаскрипте, а сейчас им сказали кодить на шарпе. S>Больше похоже как раз на Java. В которой как раз "ненужных фич нет", поэтому код получается вот такой вот убогий — трудно пишется, плохо читается, получается ненадёжным.
В лучшем случае похоже на древние версии Java, времён когда ещё c# не изобрели.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>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.
Здравствуйте, Философ, Вы писали:
Ф>простота разметки интерфейса (вёрстка интерфейса, как на 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 хоть как-то нормально пользоваться.