Здравствуйте, 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>Вроде да. Так почему они смогли реализовать это эффективно с квадратными скобками, но никак не могли с фигурными, которые использовались раньше?
Потому что ты как обычно не понимаешь сути. В фигурных скобках перечисляются объекты. А квадратные скобки используются для объявления массива/коллекции объектов.
Если нам не помогут, то мы тоже никого не пощадим.