Здравствуйте, Sinclair, Вы писали:
S>Не очень понятен смысл неиспользования null-ов. Проблема, я так понимаю, в том, что NRE упадёт слишком поздно?
Вот здесь развернутый комментарий:
OptionalValue как раз и служит для разделение опциональных и не опциональных переменных. Соответственно, для первых применяем такую запись, а для вторых обычную. А какой будет переменная T или IOptionalValue<T> определяет поставщик переменной. Если мы знаем, что поставщик соблюдает это правило, то для T можно не беспокоиться об NRE. Если поставщик не соблюдает это правило, то все как обычно, т.е. хреново: писать или не писать if, если писать, то, что внутри этого if-а делать и т.д. Глупость заключается в том, чтобы создавать эту хреновую ситуацию и в случае, если вы сами являетесь тем поставщиком. http://rsdn.ru/forum/design/3954267.1.aspx
AP>>где, что не работает? G>При такой реализации IOptionalValue метода HasValue вернет false, а GetValue не бросит исключение.
Нет такого требования!
G>Это и есть контракт, который у тебя не энфорсится никак.
Нет там никакого "кролика"(контракта) . Контракт только в твоей голове. Освободи свое сознание от шаблонов, навязанных твоей реализацией.
Re[10]: Optional Value. Уменьшение количества null reference
, но не удосужился написать ответ. G>Молча слил?
В своем посте я сделал замечание, чтобы не делали то-то и то-то, поскольку пример искусственный. Ты в своем посте сделал ровно то, что было в замечании. Ставлю минус, когда собеседник не слышит меня, и я теряю интерес к продолжению разговора.
G>Молча слил?
Минус это не “молча”.
Re[11]: Optional Value. Уменьшение количества null reference
AP>>>где, что не работает? G>>При такой реализации IOptionalValue метода HasValue вернет false, а GetValue не бросит исключение. AP>Нет такого требования!
G>>Это и есть контракт, который у тебя не энфорсится никак. AP>Нет там никакого "кролика"(контракта) . Контракт только в твоей голове. Освободи свое сознание от шаблонов, навязанных твоей реализацией.
Любая реализация Option должна быть изоморфна любой другой. Иначе нарушаешь принцип наименьшего удивления.
Re[11]: Optional Value. Уменьшение количества null reference
, но не удосужился написать ответ. G>>Молча слил? AP>В своем посте я сделал замечание, чтобы не делали то-то и то-то, поскольку пример искусственный. Ты в своем посте сделал ровно то, что было в замечании. Ставлю минус, когда собеседник не слышит меня, и я теряю интерес к продолжению разговора.
А я не должен делать как ты говоришь, ты привел пример кода, я привел аналогичный пример со своей реализацией Option, ты ничего не сказал, только минус поставил. Кроме того на вопрос не ответил, а вопрос кстати очень важный.
ЗЫ. Ты вообще не воспринимаешь критику, сразу начинаешь съезжать и придумывать небылицы. Например: нету контракта, необходима ковариантность итп. Уже не первый раз так. Не можешь адекватно вести разговор — лучше не пиши сюда.
Re[3]: Optional Value. Уменьшение количества null reference-
S>>Не очень понятен смысл неиспользования null-ов. Проблема, я так понимаю, в том, что NRE упадёт слишком поздно? AP>Смысл -- сделать безопасным базовый/основополагающий прием трансформации кода Extract Method. Т.е. избежать катастрофы при использовании Extract Method, которая описана в первом посте.
Дело в том, что я не вижу никакой катастрофы.
Вот у нас был безопасный код — мы его отрефакторили. Я надеюсь, очевидно, что в исходном коде не было никаких null.Method2()? Значит, после рефакторинга код никак не поменяет свою работоспособность.
Вторая проблема: нигде в последующем обсуждении я не вижу примера того, как Extract Method станет более безопасным. Точнее, вообще нигде нет никаких Extract Method.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Скажи, а вот ты серьёзно считаешь, что вот эти [перловские] подчёркивания (да ещё в сочетании с "=>") читабельнее шарповых слов (а хотя бы и букв) в именах переменных?
Здравствуйте, akasoft, Вы писали:
A>Скажи, а вот ты серьёзно считаешь, что вот эти [перловские] подчёркивания (да ещё в сочетании с "=>") читабельнее шарповых слов (а хотя бы и букв) в именах переменных?
Они не перловские, они хаскельные и окамловские. Иногда их употребление вполне уместно.
Глаза у меня добрые, но рубашка — смирительная!
Re[12]: Optional Value. Уменьшение количества null reference
Здравствуйте, gandjustas, Вы писали:
G>Любая реализация Option должна быть изоморфна любой другой.
Хватит уже пытаться подсунуть требования, которых нет! И которые не нужны.
G>Любая реализация Option должна быть изоморфна любой другой. Иначе нарушаешь принцип наименьшего удивления.
Если я сделаю реализацию IComparer, который будет говорить что 3 больше 2. Отсортирую им массив. Как тут насчет принципа наименьшего удивления?
A>Скажи, а вот ты серьёзно считаешь, что вот эти [перловские] подчёркивания (да ещё в сочетании с "=>") читабельнее шарповых слов (а хотя бы и букв) в именах переменных?
Стоит решить одну/две задачи с помощью такой конструкции, сравнить ее с альтернативной реализацией, и претензии отпадут сами собой.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, akasoft, Вы писали:
A>>Скажи, а вот ты серьёзно считаешь, что вот эти [перловские] подчёркивания (да ещё в сочетании с "=>") читабельнее шарповых слов (а хотя бы и букв) в именах переменных?
Q>Они не перловские, они хаскельные и окамловские. Иногда их употребление вполне уместно.
Разве что в ML языках подчеркивание применяется в ситуациях, когда значение не используется. Здесь же подчеркивание есть имя используемой переменной.
Re[4]: Optional Value. Уменьшение количества null reference-
Здравствуйте, Sinclair, Вы писали:
S>Я надеюсь, очевидно, что в исходном коде не было никаких null.Method2()?
Да, не было.
S>Дело в том, что я не вижу никакой катастрофы. S>Вот у нас был безопасный код — мы его отрефакторили. Я надеюсь, очевидно, что в исходном коде не было никаких null.Method2()? Значит, после рефакторинга код никак не поменяет свою работоспособность.
Работоспособность не изменилась, да, но надежность/безопасность снизилась. Снижение надежности вот в каком смысле. Программист делает неправильные действия, а компилятор не сообщает ему об ошибке. В коде до рефакторинга мы делаем неправильное действие: заменяем вызов конструктора “new SomeClass1()” на “null” и компилятор говорит нам “вы что-то не то делаете”. После рефакторинга, если мы сделаем такое же неправильное действие, то получим NRE только в runtime-е.
S>Вторая проблема: нигде в последующем обсуждении я не вижу примера того, как Extract Method станет более безопасным. Точнее, вообще нигде нет никаких Extract Method.
Извиняюсь, но этот абзац я не понял. В каких обсуждениях, какой пример? Пример с Extract Method-ом уже был в первом посте в разделе “Катастрофа при Extract Method”.
S>Точнее, вообще нигде нет никаких Extract Method.
В реальности этап с Extract Method-ом часто не присутствует в явном виде. Программист не рефакторит, а сразу пишет метод (или это делает вообще другой человек). Но описанная проблема присутствует и здесь. Надежность такого кода ниже по сравнению с тем, который получается после Inline Method.
Пример из реального проекта, где нужна ковариантность OptionalValue:
private static IOptionalValue<IFollowingPublicationCalculator> GetFollowingPublicationCalculator(
string catalogNumber, string precededCatalogNumber, int releaseMark)
{
if (string.IsNullOrEmpty(precededCatalogNumber))
{
return FindPreviousPublicationIdBySelfNumber(catalogNumber, releaseMark)
.ProcessValue(value => new SelfNumberFollowingPublicationCalculator(value, catalogNumber));
}
else
{
return FindPreviousPublicationIdByOtherNumber(precededCatalogNumber)
.ProcessValue(value => new OtherNumberFollowingPublicationCalculator(value, precededCatalogNumber));
}
}
Так код будет выглядеть под C# 4.0. Причем сейчас этот код под C# 3.0, и я вырезал ручные операции с типами. Вариантов записи с ручными операциями над типами много, поэтому жду, какой вариант нравится вам. Мне все варианты не нравятся, хотя в них букв не много, и если будет достаточное обоснование, то можно смириться.
через абстрактный класс рассуждения про какой-то контракт это полная чушь, конечно. Но там есть другой приятный момент. Там есть implicit operator. Т.е. кое-где не будет требоваться вызов метода “.AsOptionalValue()”.
Вот думаю, что лучше ковариантность или implicit operator? Сделать и то и другое в текущей версии C#-а, к сожалению, нельзя.
Re[13]: Optional Value. Уменьшение количества null reference
Здравствуйте, Alexander Polyakov, Вы писали:
AP>Здравствуйте, gandjustas, Вы писали:
G>>Любая реализация Option должна быть изоморфна любой другой. AP>Хватит уже пытаться подсунуть требования, которых нет! И которые не нужны.
Это ковариантность не нужна, ты до сих пор пример привести не смог даже.
А вот согласованность получения значение option и проверки наличия значения очень даже нужны. Просто потому что они в других библиотеках так сделаны.
G>>Любая реализация Option должна быть изоморфна любой другой. Иначе нарушаешь принцип наименьшего удивления. AP>Если я сделаю реализацию IComparer, который будет говорить что 3 больше 2. Отсортирую им массив. Как тут насчет принципа наименьшего удивления?
Не то сравниваешь. Тут вопрос согласованности, вот если ты сделаешь класс у которого не выполняется a.Equals(b) => a.GetHashCode() == b.GetHashCode(), то удивление будет ого-го, особенно при использовании в контейнерах.
Re[4]: Optional Value. Уменьшение количества null reference-
Здравствуйте, Sinclair, Вы писали:
S> ... как Extract Method станет более безопасным. ...
Extract Method становится безопасным при использовании техники кодирования, описанной в разделе “Катастрофа при Extract Method”.
Re[5]: Optional Value. Уменьшение количества null reference-
Здравствуйте, Alexander Polyakov, Вы писали: AP>Работоспособность не изменилась, да, но надежность/безопасность снизилась. Снижение надежности вот в каком смысле. Программист делает неправильные действия, а компилятор не сообщает ему об ошибке. В коде до рефакторинга мы делаем неправильное действие: заменяем вызов конструктора “new SomeClass1()” на “null” и компилятор говорит нам “вы что-то не то делаете”. После рефакторинга, если мы сделаем такое же неправильное действие, то получим NRE только в runtime-е.
Вы серъёзно? Лично мне описанный сценарий кажется слегка надуманным. Программист в здравом уме никогда даже не попробует заменить “new SomeClass1()” на “null”. Ни до рефакторинга, ни после.
Более реалистичным представляется замена new SomeClass1() на SomeClassFactory.Instance.GetInstance(). Но что-то мне подсказывает, что возврат null из SomeClassFactory не отловится ни компилятором, ни вашим OptionalValue.
AP>Извиняюсь, но этот абзац я не понял. В каких обсуждениях, какой пример? Пример с Extract Method-ом уже был в первом посте в разделе “Катастрофа при Extract Method”.
Нет примера того, как катастрофы Extract Method удаётся избежать при помощи OptionalValue. Может, я что-то пропустил?
Покажите мне код с экстрагированным методом, который упадёт при использовании OptionalValue, в отличие от кода без использования OptionalValue.
AP>В реальности этап с Extract Method-ом часто не присутствует в явном виде. Программист не рефакторит, а сразу пишет метод (или это делает вообще другой человек). Но описанная проблема присутствует и здесь. Надежность такого кода ниже по сравнению с тем, который получается после Inline Method.
Я, наверное, очень далёк уже от практики программирования. Я ни разу в жизни не наблюдал ошибки компилятора, о которой вы пишете. Как правило, мат ставится в два хода:
1. var x = null; // иногда — var x = GetSomeX(), который возвращает null
2. x.CallMethodRequiringNotNull(); // NRE
Против этого ваш OptionalValue ничего интересного не предлагает. Как, впрочем, и компилятор.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: Optional Value. Уменьшение количества null reference
. Ковариантность нужна .
G>>>Любая реализация Option должна быть изоморфна любой другой. AP>>Хватит уже пытаться подсунуть требования, которых нет! И которые не нужны. G>... согласованность получения значение option и проверки наличия значения очень даже нужны. Просто потому что они в других библиотеках так сделаны.
Поведение моих реализаций согласовано с аналогичными реализациями в других библиотеках. Ты дописываешь свою реализацию, которую делаешь несогласованной с другими библиотеками. Почему претензии к результатам работы моего кода? Мой код делает ровно то, что заявлено, не больше, не меньше.
G>>>Любая реализация Option должна быть изоморфна любой другой. Иначе нарушаешь принцип наименьшего удивления. AP>>Если я сделаю реализацию IComparer, который будет говорить что 3 больше 2. Отсортирую им массив. Как тут насчет принципа наименьшего удивления? G>Не то сравниваешь. Тут вопрос согласованности, вот если ты сделаешь класс у которого не выполняется a.Equals(b) => a.GetHashCode() == b.GetHashCode(), то удивление будет ого-го, особенно при использовании в контейнерах.
Неплохая аналогия, да, тут надо делать согласованную реализацию двух методов. Аналогичные проблемы я отмечал для варианта, когда в интерфейсе IOptionalValue два свойства Value и HasValue. В моем коде у IOptionalValue метод один, поэтому согласовывать нечего.
Re[6]: Optional Value. Уменьшение количества null reference-
Здравствуйте, Sinclair, Вы писали:
AP>>Работоспособность не изменилась, да, но надежность/безопасность снизилась. Снижение надежности вот в каком смысле. Программист делает неправильные действия, а компилятор не сообщает ему об ошибке. В коде до рефакторинга мы делаем неправильное действие: заменяем вызов конструктора “new SomeClass1()” на “null” и компилятор говорит нам “вы что-то не то делаете”. После рефакторинга, если мы сделаем такое же неправильное действие, то получим NRE только в runtime-е. S>Вы серъёзно? Лично мне описанный сценарий кажется слегка надуманным. Программист в здравом уме никогда даже не попробует заменить “new SomeClass1()” на “null”. Ни до рефакторинга, ни после. S>Более реалистичным представляется замена new SomeClass1() на SomeClassFactory.Instance.GetInstance(). Но что-то мне подсказывает, что возврат null из SomeClassFactory не отловится ни компилятором, ни вашим OptionalValue.
Ага, я уже догадался, что вы напишете такое. И с некоторым запозданием я добавил комментарий:
Extract Method становится безопасным при использовании техники кодирования, описанной в разделе “Катастрофа при Extract Method”. http://rsdn.ru/forum/design/3955011.1.aspx
Вы его заметили? Полное описание техники кодирования в первом посте. Если в вкратце, то это: не использование “return null(схематичное обозначение)” + OptionalValue.
S>Покажите мне код с экстрагированным методом, который упадёт при использовании OptionalValue, в отличие от кода без использования OptionalValue.
В абзаце выше уже написал, что OptionalValue в сочетании c не использованием “return null(схематичное обозначение)”.
AP>>Как правило, мат ставится в два хода: S>1. var x = null; // иногда — var x = GetSomeX(), который возвращает null S>2. x.CallMethodRequiringNotNull(); // NRE
Ага, именно это я и хотел показать Extract Method-ом, что проблема возникает как раз при разбиении задачи на два хода.
S>Против этого ваш OptionalValue ничего интересного не предлагает. Как, впрочем, и компилятор.
OptionalValue нацелен не напрямую на это. Его прямая цель -- реализация optional логики. Да, наверное, в заголовок лучше вынести последнее. Сейчас не самый удачный заголовок.
Re[4]: Optional Value. Уменьшение количества null reference-
Здравствуйте, IT, Вы писали:
IT>Но без ПМ этим пользоваться не очень удобно.
Всё же чем не удобно? Я почти не знаком с pattern-matching, но пока я вижу, что в частном случае опциональных значений совпадении один к одному с OptionalValue. Например:
Pattern-matching
match dict.TryGetValue "Brian" with
| Some(r) -> Console.WriteLine("Brian's favorite 32-bit integer is {0}", r)
| None -> ()
Здравствуйте, gandjustas, Вы писали:
G>Ну это неверно. Maybe монада и была придумана, как средство описать частичные вычисления, которые могут не возвращать результат в некоторых случаях. Правда имеет смысл как можно дольше оставаться в этой самой монаде, а метод Process такой способностью не обладает.
В том то и дело, что для практических целей помимо самой монады важно то, как осуществляется выход из этой монады. Метод Process как раз и является безопасным выходом из монады в отличие от небезопасного GetValue.