По большей части я согласен скорее с вами, чем с автором оригинальной статьи. Кроме одного пункта — пункта 7.
Комментарии по определению это такие пометки, присутствие или отсутствие которых в коде не меняет поведения кода. Так во всех языках. Ну, разве что в Python встречаются любители хранить метаданные в docstring'ах, но их даже коллеги за это колотят. А тут вы говорите, что вызывать из комментариев кодогенератор — это норма. Кодогенератор, Карл! Да даже в C++ максросы сделаны лучше. А что, если этот комментарий сольётся с комментарием к функции ниже? В общем, можно сколько угодно защищать такое решение, ссылаясь на авторитет Пайка, но это реально выглядит на решение из разряда «да ну, для одного кейса не будем прагмы добавлять, сделаем магический комент и так сойдёт»
>>Ваш опыт идет вразрез с опытом индустрии.
Очень громкое заявление. «Индустрия» это и C# и C++ и Scala и Haskell и у меня такое чувство, что «опыт индустрии» это такая же иллюзорная вешь, как «общечеловеческая мораль».
>> при чём тут setter?
При том, что вот такой код
void Spoil(Unit unit)
{
unit.Id = 13;
}
в случае использования моих record'ов (ну или record'ов в других языках) просто не скомпилируется. Const такого не обеспечит.
>>Но гарантий const по опыту других языков — достаточно.
А по моему опыту — недостаточно.
>>Прямо физических ограничений на изменение объекта у вас нету нигде. В C# есть рефлексия
Согласен. Тут только язык переделывать. Но всё-же, это сложнее, чем вызвать setter.
>>Я выше показал что не на любую.
Во-первых, я написал, что «обычно». Во-вторых — не показали. Поясню. Вы приводили в пример запись из 10 потоков в ConcurrentDictionary, но такой алгоритм — это скорее всего решение какой-то другой задачи, и не факт, что её нельзя было решить другим образом. Из вредности я тоже могу придумать задачу, которую с mutable значениями будет решать очень геморройно, но зачем?
Я понимаю вас и вашу позицию, но мой опыт говорит о другом. Давайте не будем дальше спорить и уважать позицию друг друга?)
Ничего он не говорит в своей сигнатуре. void может означать как «я меняю объект unit» так и «я вывожу на экран объект unit». В общем, между соглашениями/правилами и физической невозможностью поменять объект я выбираю второе, ибо надёжнее.
Насчёт аргумента «иногда нужно менять объект» отвечу, что обычно на любую реализацию с изменяемыми объектами найдётся реализация с неизменяемыми
Человека может const или val и остановит, а вот такой метод
void Spoil(Unit unit)
{
unit.Id = 13;
}
— нет.
Я считаю, что если объект неизменяемый, то не должно быть способа его изменить. Это удобно, когда, например, нужно реализовать rollback операции или цепочки операций: просто берём старую версию объекта без боязни, что её испортил метод вроде метода выше.
Опишу отличия:
— структура в C# — тип значение, класс (генерируемый из описания record) — ссылочный тип, структура будет всегда копироваться, record можно передавать по ссылке
— в структуре нужно будет вручную писать конструктор с параметрами для инициализации всех полей
— так-же нужно будет написать вручную метод Copy(), с параметрами, имеющими значения по умолчанию, либо по методу With для каждого параметра. Эти методы нужны для удобной работы с такими объектами. Конечно, можно их пересоздавать вручную через конструктор, но опыт использования Scala показал более удобный путь
— вручную переопределить Equals, GetHashCode, ==, !==
в общем, написать много шаблонного и типового кода
Резюмируя, это не «неоднозначаные и непровереные плюшки», это провереная практика из «настоящих» функциональных языков, которую очень хотелось бы иметь в C#.
Да, можно, более того, это и сейчас является промежуточной стадией
До этого у меня была идея модификации кода с помошью PostSharp, но это оказалось неудобно из-за того, что аспекты инжектируются после компиляции и метод Copy не виден для IDE и инструментов на этапе разработки.
Насчёт Яндекс.Навигатора — просто в точку! У меня ахроматопсия и неразличимые по яркости цвета просто бесят (скриншот в постскриптуме нереально контрастный, на экранах реальных устройств всё часто намного хуже)
Я думаю, что речь тут о том, что когда Scala уже выучена — зачем учить ещё и Groovy, который кроме как для конфигурирование Gradle всё равно больше нигде смысла использовать нет в случае проекта на Scala
Понял вас. В принципе, я согласен со всеми доводами, они все входят в мой внутренний список причин, по которым использование Java в принципе не оправдано)
Комментарии по определению это такие пометки, присутствие или отсутствие которых в коде не меняет поведения кода. Так во всех языках. Ну, разве что в Python встречаются любители хранить метаданные в docstring'ах, но их даже коллеги за это колотят. А тут вы говорите, что вызывать из комментариев кодогенератор — это норма. Кодогенератор, Карл! Да даже в C++ максросы сделаны лучше. А что, если этот комментарий сольётся с комментарием к функции ниже? В общем, можно сколько угодно защищать такое решение, ссылаясь на авторитет Пайка, но это реально выглядит на решение из разряда «да ну, для одного кейса не будем прагмы добавлять, сделаем магический комент и так сойдёт»
Проект и расширение вот здесь: github.com/danslapman/RecSharp.VisualStudio
Необходимо создать файл с расширением .rcs
Очень громкое заявление. «Индустрия» это и C# и C++ и Scala и Haskell и у меня такое чувство, что «опыт индустрии» это такая же иллюзорная вешь, как «общечеловеческая мораль».
>> при чём тут setter?
При том, что вот такой код
в случае использования моих record'ов (ну или record'ов в других языках) просто не скомпилируется. Const такого не обеспечит.
А по моему опыту — недостаточно.
>>Прямо физических ограничений на изменение объекта у вас нету нигде. В C# есть рефлексия
Согласен. Тут только язык переделывать. Но всё-же, это сложнее, чем вызвать setter.
>>Я выше показал что не на любую.
Во-первых, я написал, что «обычно». Во-вторых — не показали. Поясню. Вы приводили в пример запись из 10 потоков в ConcurrentDictionary, но такой алгоритм — это скорее всего решение какой-то другой задачи, и не факт, что её нельзя было решить другим образом. Из вредности я тоже могу придумать задачу, которую с mutable значениями будет решать очень геморройно, но зачем?
Я понимаю вас и вашу позицию, но мой опыт говорит о другом. Давайте не будем дальше спорить и уважать позицию друг друга?)
Насчёт аргумента «иногда нужно менять объект» отвечу, что обычно на любую реализацию с изменяемыми объектами найдётся реализация с неизменяемыми
— нет.
Я считаю, что если объект неизменяемый, то не должно быть способа его изменить. Это удобно, когда, например, нужно реализовать rollback операции или цепочки операций: просто берём старую версию объекта без боязни, что её испортил метод вроде метода выше.
Допустим, есть такой объект
Создаём его:
что помешает мне вот так испортить объект:
— структура в C# — тип значение, класс (генерируемый из описания record) — ссылочный тип, структура будет всегда копироваться, record можно передавать по ссылке
— в структуре нужно будет вручную писать конструктор с параметрами для инициализации всех полей
— так-же нужно будет написать вручную метод Copy(), с параметрами, имеющими значения по умолчанию, либо по методу With для каждого параметра. Эти методы нужны для удобной работы с такими объектами. Конечно, можно их пересоздавать вручную через конструктор, но опыт использования Scala показал более удобный путь
— вручную переопределить Equals, GetHashCode, ==, !==
в общем, написать много шаблонного и типового кода
Резюмируя, это не «неоднозначаные и непровереные плюшки», это провереная практика из «настоящих» функциональных языков, которую очень хотелось бы иметь в C#.
До этого у меня была идея модификации кода с помошью PostSharp, но это оказалось неудобно из-за того, что аспекты инжектируются после компиляции и метод Copy не виден для IDE и инструментов на этапе разработки.
Сам пишу в Sublime и RustyCage
Я, честно говоря, не представляю, как можно не видеть полезности проверки диапазонов значений.