Здравствуйте, Ночной Смотрящий, Вы писали:
ARK>>Было бы четкое разделение
НС>В чем профит?
Снижение когнитивной нагрузки. Видишь рекорд — все, ты сразу знаешь, что наломать с ним дров нельзя. Индус Вася не сможет туда завтра добавить мутабельное поле и у тебя где-то в глубине не сломается хеш-таблица, как в примере выше. Меньше обращаешь внимания на это.
Здравствуйте, AlexRK, Вы писали:
ARK>Снижение когнитивной нагрузки. Видишь рекорд — все, ты сразу знаешь, что наломать с ним дров нельзя.
Какой то сомнительный профит.
ARK> Индус Вася не сможет туда завтра добавить мутабельное поле и у тебя где-то в глубине не сломается хеш-таблица, как в примере выше. Меньше обращаешь внимания на это.
Если у тебя индусы-васи могут куда то чего то бездумно в твой код добавить — у тебя большие проблемы вне зависимости от свойств рекордов.
Здравствуйте, Ночной Смотрящий, Вы писали:
ARK>>Снижение когнитивной нагрузки. Видишь рекорд — все, ты сразу знаешь, что наломать с ним дров нельзя. НС>Какой то сомнительный профит.
А какой профит от того, что мутабельность оставили?
ARK>> Индус Вася не сможет туда завтра добавить мутабельное поле и у тебя где-то в глубине не сломается хеш-таблица, как в примере выше. Меньше обращаешь внимания на это. НС>Если у тебя индусы-васи могут куда то чего то бездумно в твой код добавить — у тебя большие проблемы вне зависимости от свойств рекордов.
Тогда и readonly поля не нужны. Ведь можно использовать обычные. Просто не пиши туда ничего лишнего.
Здравствуйте, AlexRK, Вы писали:
ARK>Ога?
Now we're talking.
То есть вы самостоятельно добавили set, и внезапно рекорд перестал себя вести так, как ведёт, я всё правильно понял?
А то, что язык и компилятор подталкивают вас писать public record MyRecord(int Value, bool Danger) — этого недостаточно?
Так-то мы знаем, что и string — нифига не immutable.
ARK>Не понимаю, нахрена делать мутабельность? Вот что это кому дает?
Например, это позволяет мне вносить в рекорды состояние, не влияющее на эквивалентность.
public Manager {
get
{
if (_manager == null)
{
_manager = DB.Instance.Managers.GetManagerById()
}
return _manager;
}
}
Полный запрет изменяемости обрубил бы эту возможность.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Serginio1, Вы писали:
S>>Про рекорды
IT>Что-то я не вижу, деконструктор они туда прикрутили?
Ага. Подозреваю, что можно несколько упростить код Linq.Expressions.Deconstruct.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали: S>Спасибо, я ещё не привык
Копец, как это вслух-то читать?
Для ?! есть название — интерробанг.
А ??= как читать? Не произносить же кажный раз "null-coalescing assignment operator"...
manager what-what-assign from deebee dot instance dot managers dot get manager by id
?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, Serginio1, Вы писали:
S>> А вот кому то она возможно и будет нужна.
ARK>Вот этого я и не могу понять. Если такая возможность нужна — почему просто не взять обычный класс? Для генерации всяких вспомогательных методов вводить в язык фичи необязательно.
ARK>Было бы четкое разделение — вот потенциально изменяемый класс, вот гарантированно неизменяемый рекорд.
Не добавляй мутабельные поля вот и все.
S>>И он будет плеваться из-за того, что такой возможности нет.
ARK>Почему тогда, скажем, анонимные классы мутабельными не сделали? Может кто-то плюется, что их нельзя поменять.
Анонимные классы без рефлексии в методах не поиспользуешь. Особого смысла нет.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
ARK>>Было бы четкое разделение — вот потенциально изменяемый класс, вот гарантированно неизменяемый рекорд. S> Не добавляй мутабельные поля вот и все.
Если ты и автор и пользователь рекорда, то да.
Но представь такой случай: ты используешь рекорд Foo, определенный в некоторой библиотеке. Чтобы узнать, изменяемы ли его поля или нет, тебе нужно лезть в сорцы этой библиотеки, т.к. по public contract этого не видно. Даже если в текущей версии библиотеки он неизменяем, ничто не мешает в следующей ее версии сделать некоторые поля рекорда изменяемыми. А все потому, что (не)изменяемость рекорда это деталь его реализации, никак не выраженная в его контракте.
Здравствуйте, AlexRK, Вы писали:
ARK>>>Снижение когнитивной нагрузки. Видишь рекорд — все, ты сразу знаешь, что наломать с ним дров нельзя. НС>>Какой то сомнительный профит. ARK>А какой профит от того, что мутабельность оставили?
В том что сахар будет доступен и там, где дизайн изначально мутабельный. К примеру, не все десериализаторы умеют десериализовать в конструктор, к примеру тот же ConfigurationBinder.
ARK>>> Индус Вася не сможет туда завтра добавить мутабельное поле и у тебя где-то в глубине не сломается хеш-таблица, как в примере выше. Меньше обращаешь внимания на это. НС>>Если у тебя индусы-васи могут куда то чего то бездумно в твой код добавить — у тебя большие проблемы вне зависимости от свойств рекордов. ARK>Тогда и readonly поля не нужны. Ведь можно использовать обычные. Просто не пиши туда ничего лишнего.
Доказательство по аналогии? Еще раз — если ты не напишешь явно, что свойство мутабельное — компилятор тебе его поменять не даст. Ровно тоже делают и readonly. Ты же предлагаешь вообще все поля безусловно сделать readonly чтобы индусы вдруг его не поменяли.
Здравствуйте, Serginio1, Вы писали:
ARK>>Почему тогда, скажем, анонимные классы мутабельными не сделали? Может кто-то плюется, что их нельзя поменять. S> Анонимные классы без рефлексии в методах не поиспользуешь.
Здравствуйте, artelk, Вы писали:
A>Но представь такой случай: ты используешь рекорд Foo, определенный в некоторой библиотеке. Чтобы узнать, изменяемы ли его поля или нет, тебе нужно лезть в сорцы этой библиотеки, т.к. по public contract этого не видно. Даже если в текущей версии библиотеки он неизменяем, ничто не мешает в следующей ее версии сделать некоторые поля рекорда изменяемыми.
И при чем тут рекорды? Ровно то же ты можешь получить и с классами.
A> А все потому, что (не)изменяемость рекорда это деталь его реализации,
Нет. Это деталь его публичного контракта.
A> никак не выраженная в его контракте.
Здрасте, приехали. Наличие set вместо init это контракт и есть.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Serginio1, Вы писали:
ARK>>>Почему тогда, скажем, анонимные классы мутабельными не сделали? Может кто-то плюется, что их нельзя поменять. S>> Анонимные классы без рефлексии в методах не поиспользуешь.
НС>Вот это новость.
Имелось ввиду при передачи объекта анонимного класса в параметрах.
Поэтому и нет особой нужды в мутабельности
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
S>То есть вы самостоятельно добавили set, и внезапно рекорд перестал себя вести так, как ведёт, я всё правильно понял?
Индус Вася добавил set в общий рекорд для того, чтобы ему в своем кусочке кода было удобнее.
Смотрит — вроде все работает.
Да, да, я знаю, что такого быть не может, и что вся функциональность, внешняя и внутренняя, всегда на 100% покрыта всеми возможными тестами.
S>А то, что язык и компилятор подталкивают вас писать public record MyRecord(int Value, bool Danger) — этого недостаточно? S>Например, это позволяет мне вносить в рекорды состояние, не влияющее на эквивалентность. S>Полный запрет изменяемости обрубил бы эту возможность.
В тех полутора местах, где такое нужно, можно просто использовать обычный класс.
Здравствуйте, Ночной Смотрящий, Вы писали:
ARK>>А какой профит от того, что мутабельность оставили? НС>В том что сахар будет доступен и там, где дизайн изначально мутабельный. К примеру, не все десериализаторы умеют десериализовать в конструктор, к примеру тот же ConfigurationBinder.
Чем плох обычный класс в таком месте?
ARK>>Тогда и readonly поля не нужны. Ведь можно использовать обычные. Просто не пиши туда ничего лишнего. НС>Доказательство по аналогии? Еще раз — если ты не напишешь явно, что свойство мутабельное — компилятор тебе его поменять не даст. Ровно тоже делают и readonly. Ты же предлагаешь вообще все поля безусловно сделать readonly чтобы индусы вдруг его не поменяли.
readonly поле — это гарантия на уровне поля.
record мог бы быть гарантией на уровне композитного объекта с именованным доступом.
Здравствуйте, AlexRK, Вы писали:
НС>>В том что сахар будет доступен и там, где дизайн изначально мутабельный. К примеру, не все десериализаторы умеют десериализовать в конструктор, к примеру тот же ConfigurationBinder. ARK>Чем плох обычный класс в таком месте?
Тем же, чем и в любом другом месте, в котором планируется использовать рекорды.
НС>>Доказательство по аналогии? Еще раз — если ты не напишешь явно, что свойство мутабельное — компилятор тебе его поменять не даст. Ровно тоже делают и readonly. Ты же предлагаешь вообще все поля безусловно сделать readonly чтобы индусы вдруг его не поменяли. ARK>readonly поле — это гарантия на уровне поля. ARK>record мог бы быть гарантией на уровне композитного объекта с именованным доступом.
Вопрос в том насколько такая гарантия нужна. Тем более что просто запрета тут недостаточно, ибо тогда твой неконтролируемый Вася-индус может с таким же успехом поменять рекорд на класс и таки все сломать. Соотв. как минимум нужен еще и констрейн на рекорд. Но в таком случае констрейн лучше сделать не на рекорд, а вообще на иммутабельный класс, неважно, рекорд он или обычный. И в таком разрезе принудительная иммутабильность рекордов опять же лишена практического смысла.
ARK>А что щас сделали, хрен знает.
Сделали удобный инструмент, позволяющий не писать кучу бойлерплейта в ряде ситуаций.
