Comments 18
По этой же причине не рекомендуется в апи делать методы со значениями по умолчанию — значение поменяете, а без пересборки зависимых сборок результата не получите.
А можно подробности? Имеется в виду дефолтное значение для автосвойств?
Нет, имеется в виду void Method(bool critical = false). Если вызвать из другого проекта как Method(), затем поменять дефолтное значение, и подложить сборку без перекомпиляции зависимой сборки — будет старый дефолт.
имеется в виду аргументы по умолчанию:
собственно потому многие дотнет классы имеют кучу перегрузок на методы, вместо параметров по умолчанию.
void Test(string arg="arg")
собственно потому многие дотнет классы имеют кучу перегрузок на методы, вместо параметров по умолчанию.
Наверное всё-таки не поэтому, а из-за тяжелого наследия C# 3.0 и ранее, где значений по-умолчанию не было.
В VB они были изначально и ничего.
И я не припомню чтобы кто-то в здравом уме менял значения по-умолчанию в каких-либо библиотеках, это ж весь софт который их использует, полетит нафиг. И уже будет не важно где они там хранятся.
В VB они были изначально и ничего.
И я не припомню чтобы кто-то в здравом уме менял значения по-умолчанию в каких-либо библиотеках, это ж весь софт который их использует, полетит нафиг. И уже будет не важно где они там хранятся.
А вот Scala здесь умная: вычисление значения по умолчанию компилируется в метод, так что при изменении значения по умолчанию поменяется код вызванного метода, а на вызывающей стороне изменений никаких нет и не должно быть.
del
Была схожая проблема но с enum:
Есть enum который содержит список операций. За этот enam, а также и за библиотеку (DLL), его использующую отвечает разработчик А. Этот enam входит в другую библиотеку.
Разработчик Б использует эту библиотеку (DLL).
Разработчик А допустил ошибку в enum и прислал новую версию библиотеки (DLL) разработчику Б.
У разработчика Б проявлялся странный баг, было установлено, что причина в этом enam (использовался рефлектор).
Заменяется сборка с enam, где ошибка исправлена — баг остается.
Рефлектор показывает, что в библиотеке (DLL) разработчика А используется старое значение (в виде byte).
Только когда библиотека (DLL) была пересобрана с исправленной версией enam проблема была решена.
Есть enum который содержит список операций. За этот enam, а также и за библиотеку (DLL), его использующую отвечает разработчик А. Этот enam входит в другую библиотеку.
Разработчик Б использует эту библиотеку (DLL).
Разработчик А допустил ошибку в enum и прислал новую версию библиотеки (DLL) разработчику Б.
У разработчика Б проявлялся странный баг, было установлено, что причина в этом enam (использовался рефлектор).
Заменяется сборка с enam, где ошибка исправлена — баг остается.
Рефлектор показывает, что в библиотеке (DLL) разработчика А используется старое значение (в виде byte).
Только когда библиотека (DLL) была пересобрана с исправленной версией enam проблема была решена.
оно логично, enum по сути набор констант.
У нас была анологичная проблема с enum при переходе c WiX 3.9 на 3.10
Столкнувшись с похожей проблемой с enum стали использовать следующий подход: Enumeration classes.
Далее в программе «Удивительное и невероятное из документации по .NET»: структуры передаются по значению, приведение примитива к
object вызывает боксинг, строки являются неизменяемыми…Вы правы: зевнул док при написании статьи.
Неоднократно встречал эту информацию в разных книжках прямо в определении того, что такое константа в clr и в голову не приходило ставить его под сомнение. Когда появились параметры со значениями по умолчанию, то принцип их работы и поведение так же были описаны. Мне кажется этот факт не стоит выносить дальше помещения, где коллеги-разработчики обсуждают новые фишечки языка. Копипастер статью скорее всего не встретит, он обитает на stackexchange, где и скопирует кусок кода про значения по умолчанию.
Это все-таки не бага, а фича. У Рихтера можно почитать, если не ошибаюсь.
А по поводу nameof — все то же самое, вычисляется в compile-time и записывается как константа. Недавно проверял.
А по поводу nameof — все то же самое, вычисляется в compile-time и записывается как константа. Недавно проверял.
Использую по этой причине static readonly почти всегда.
Sign up to leave a comment.
Константы не меняются: небольшой экскурс в глубины dotNet