Здравствуйте, _FRED_, Вы писали:
_FR>>>Ты же сам сообщением выше призывал всюду юзингом пользоваться!? A>>Где это я "призывал всюду юзингом пользоваться"? Просмотрел свои сообщения еще раз — не нашел никаких призывов. _FR>
_FR>_Лично_я_ считаю, что вне блока using объект, в нем используемый, жить не должен. У него и область видимости-то должна быть ограничена этим блоком. Тогда using четко указывает область жизнь и использования объекта. На мой взгляд, это способствует простоте и понятности кода.
Хм. Специально выделенные слова "лично я" — это призыв всюду пользоваться using'ом? Был уверен, что это описание того, как _лично_я_ считаю правильным делать.
_FR>О том, что речь в этих словах идёт о каком-то конкретном юз-кейсе, а не о любом IDisposable-объекте мне, например, было не ясно :xz:
Постараюсь в будущем более четко формулировать свои мысли.
Кстати, когда я там предложил напрямую вызывать Dispose вместо using'а (который я якобы призывал использовать везде), тебя не насторожила такая непоследовательность? :)
A>>Понял, спасибо. Правда, есть сомнения в целесообразности подобного (именно со стримом) — с точки зрения производительности. Думаю, ненужная работа со пустым стримом может в некоторых случаях занять ощутимое время.
_FR>Например?
Например, запись в цикле в пустой стрим большого количества данных. Есть сомнения, что это будет сравнимо по времени со случаем, когда стрим проверяется на null и никакой записи не производится вообще. Особенно, если при этом записываемые данные вычисляются по ходу записи.
_FR>за счёт чего получится "ощутмость"?
За счет вызовов методов, которые ничего не делают. Понятно, что вызов метода это копеечные накладные расходы в общем случае. Но на фоне нулевых затрат времени и ресурсов на работу самого метода расходы на вызов этого метода все же не нулевые, особенно если метод виртуальный. А то, что мало, но не равно нулю, при "умелом" использовании вполне реально многократно увеличить до статистически значимых величин.
Это я не в плане поспорить, что эти копеечные затраты важны, и надо за них биться насмерть любыми способами, а в целях объяснения, за счет чего может получиться "ощутимость". То, что в большинстве случаев про это можно не думать, не означает, что про это думать не следует вообще. Иногда это может быть критично. Иногда.
Re[17]: using Statement и отложенная инициализация
Здравствуйте, amx3000, Вы писали:
A>>>Понял, спасибо. Правда, есть сомнения в целесообразности подобного (именно со стримом) — с точки зрения производительности. Думаю, ненужная работа со пустым стримом может в некоторых случаях занять ощутимое время.
_FR>>Например?
A>Например, запись в цикле в пустой стрим большого количества данных. Есть сомнения, что это будет сравнимо по времени со случаем, когда стрим проверяется на null и никакой записи не производится вообще. Особенно, если при этом записываемые данные вычисляются по ходу записи.
Ты не обратил внимание на первую часть предложения:
…когда надо возвратить стрим и по каким-то причинам не удаётся, следует или бросить исключение или вернуть Stream.Null, но не "null".
Теперь в методе, который чо-то возвращает до должен отдать или рабочий стрим, или сказать, что отдать ничего не можешь. Как по-твоему, по какой причине File.Open(…) не возвращает null в случае неудачи, а выбрасывает исключение? А я тебе скажу: чтобы избавить вызывающего от принятия решения и ненужной (вызывающему) проверки.
_FR>>за счёт чего получится "ощутмость"?
A>За счет вызовов методов, которые ничего не делают.
Об этом должен думать метод, возвращающий стрим: Что будет делать вызывающая строна с результатом? Приведи пример, когда возврат null по твоему мнению будет лучше, чем бросание исключения или возврата Stream.Null?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Help will always be given at Hogwarts to those who ask for it.
Re[17]: using Statement и отложенная инициализация
Здравствуйте, amx3000, Вы писали:
A>Здравствуйте, _FRED_, Вы писали:
A>>>Понял, спасибо. Правда, есть сомнения в целесообразности подобного (именно со стримом) — с точки зрения производительности. Думаю, ненужная работа со пустым стримом может в некоторых случаях занять ощутимое время.
_FR>>за счёт чего получится "ощутмость"?
A>За счет вызовов методов, которые ничего не делают. Понятно, что вызов метода это копеечные накладные расходы в общем случае. Но на фоне нулевых затрат времени и ресурсов на работу самого метода расходы на вызов этого метода все же не нулевые, особенно если метод виртуальный. А то, что мало, но не равно нулю, при "умелом" использовании вполне реально многократно увеличить до статистически значимых величин.
A>Это я не в плане поспорить, что эти копеечные затраты важны, и надо за них биться насмерть любыми способами, а в целях объяснения, за счет чего может получиться "ощутимость". То, что в большинстве случаев про это можно не думать, не означает, что про это думать не следует вообще. Иногда это может быть критично. Иногда.
Мне кажется, метод, возвращающий этот самый Stream.Null, не должен заботиться о производительности метода, который его вызывает — не его это дело. "Зовущий" метод сам может проверить результат на Stream.Null и не делать "ощутимые" записи, сэкономив время.
Цимес Stream.Null'а в таком случае в том, что такая проверка становится опциональной, и без нее не упадет — хотите, экономьте время, пишите доп.логику, устраивает и так — не проверяйте, stream.null такой же поток, как и все остальные; важно то, что в любом случае усложнение кода не навязывается и в любом случае ничего не свалится.
Re[18]: using Statement и отложенная инициализация
Здравствуйте, meowth, Вы писали:
M>Мне кажется, метод, возвращающий этот самый Stream.Null, не должен заботиться о производительности метода, который его вызывает — не его это дело. "Зовущий" метод сам может проверить результат на Stream.Null и не делать "ощутимые" записи, сэкономив время. M>Цимес Stream.Null'а в таком случае в том, что такая проверка становится опциональной, и без нее не упадет — хотите, экономьте время, пишите доп.логику, устраивает и так — не проверяйте, stream.null такой же поток, как и все остальные; важно то, что в любом случае усложнение кода не навязывается и в любом случае ничего не свалится.
Свалиться-то не свалится, но тихо перестанет корректно работать, нафиг нужен такой цимес. Если сам по себе Stream.Null еще имеет право на существование, то возврат его при возникновении исключительной ситуации вместо выброса исключения — грубейшая ошибка дизайна.
Re[18]: using Statement и отложенная инициализация
…когда надо возвратить стрим и по каким-то причинам не удаётся, следует или бросить исключение или вернуть Stream.Null, но не "null".
Ок, выбрасывание исключения вполне вписывается в мое чувство прекрасного. А целесообразность Stream.Null для себя лично я так и не осознал. Буду над этим работать.
_FR>>>за счёт чего получится "ощутмость"? A>>За счет вызовов методов, которые ничего не делают. _FR>Об этом должен думать метод, возвращающий стрим
Об этом должен думать программист.
Re[19]: using Statement и отложенная инициализация
Здравствуйте, amx3000, Вы писали:
_FR>>>>за счёт чего получится "ощутмость"? A>>>За счет вызовов методов, которые ничего не делают. _FR>>Об этом должен думать метод, возвращающий стрим
A>Об этом должен думать программист.
Фу как не красиво. Апочему не тётушка програмиста? К чему этьо замечание вообще добавлено? Что означает и как его надо понимать? Как к нему относиться? ИМХО, это из разряда "что бы ни сказать, лишь бы сказать" нет, серьёздно, ты какую реакцию ожидаешь на эти слова
Help will always be given at Hogwarts to those who ask for it.
Re[20]: using Statement и отложенная инициализация
Здравствуйте, _FRED_, Вы писали:
_FR>>>Об этом должен думать метод, возвращающий стрим A>>Об этом должен думать программист.
_FR>Апочему не тётушка програмиста?
Наверное, потому что код пишет не тетушка программиста.
_FR>К чему этьо замечание вообще добавлено?
Это ответ на твой вопрос — кто должен думать.
_FR>Что означает и как его надо понимать? ИМХО, это из разряда "что бы ни сказать, лишь бы сказать" нет, серьёздно, ты какую реакцию ожидаешь на эти слова
Я, собственно, дискуссию со своей стороны на этом заканчиваю, хотя надо было еще раньше это сделать. Конструктивная часть давно закончилась, как мне кажется. Спасибо за внимание.
Re[18]: using Statement и отложенная инициализация
Здравствуйте, meowth, Вы писали:
M>Мне кажется, метод, возвращающий этот самый Stream.Null, не должен заботиться о производительности метода,
который его вызывает — не его это дело.
Метод, возвращающий пустой стрим, естественно не должен заботиться о том, как этот стрим будет использоваться в дальнейшем. Только зачем его возвращать? Какой в этом глубокий смысл? Экономия на обработке исключений? Выполнение кода, который можно не выполнять?
M>"Зовущий" метод сам может проверить результат на Stream.Null и не делать "ощутимые" записи, сэкономив время.
В таком дизайне еще меньше смысла, чем в работе со стрим.нулл как с нормальным полноценным стримом. А если в дизайне нет смысла, значит это неправильный дизайн.
Вместо того, чтобы возвращать стрим.нулл и не заботиться о том, что там будет дальше, лучше сразу выбрасывать исключение "файл не соответствует ожиданиям".
M>Цимес Stream.Null'а в таком случае в том, что такая проверка становится опциональной, и без нее не упадет — хотите, экономьте время, пишите доп.логику, устраивает и так — не проверяйте, stream.null такой же поток, как и все остальные; важно то, что в любом случае усложнение кода не навязывается и в любом случае ничего не свалится.
Ага. Просто в один прекрасный момент, через пару лет развития программы, вдруг все начнет адски тормозить и жрать память, не падая. И кому-то придется, тихонько матерясь на толковых предшественников, исправлять все возвраты Stream.Null на нормальный выброс и обработку исключений.
Или, что еще хуже, — не вдруг, а просто все будет работать медленно. Не критически медленно, чтобы пользователи забили тревогу, а так, вызывая небольшое раздражение. Просто потому что сэкономили на обработке исключений в одном месте, в другом, в десятом... Ничего не валится же, значит все ок.
Извините за лирику, это у меня сейчас личное прорвалось :)
Re[19]: using Statement и отложенная инициализация
Здравствуйте, amx3000, Вы писали:
A>Здравствуйте, meowth, Вы писали:
A>Ага. Просто в один прекрасный момент, через пару лет развития программы, вдруг все начнет адски тормозить и жрать память, не падая. И кому-то придется, тихонько матерясь на толковых предшественников, исправлять все возвраты Stream.Null на нормальный выброс и обработку исключений. A>Или, что еще хуже, — не вдруг, а просто все будет работать медленно. Не критически медленно, чтобы пользователи забили тревогу, а так, вызывая небольшое раздражение. Просто потому что сэкономили на обработке исключений в одном месте, в другом, в десятом... Ничего не валится же, значит все ок.
A>Извините за лирику, это у меня сейчас личное прорвалось
Лирику понимаю, сам такой — могу вам страшных историй понарассказывать
Ну таки я ж не призываю этим заменять exceptions или экономить на них. Если есть исключительная ситуация — однозначно бросать эксепшен. А Stream.Null возвращать (или передавать, например), только если это логически оправданно, а не как сигнал об ошибке; и соображения производительности здесь не стоит вообще учитывать.Как пример юзкейса — метод, который делает что-то и еще что-то пишет в поток (журнала, например). Если мы хотим это проигнорировать, то передаем Stream.Null, и все.
P.S. То же самое относится адресую и предыдущему комментатору
Re[20]: using Statement и отложенная инициализация
Здравствуйте, meowth, Вы писали:
M>Ну таки я ж не призываю этим заменять exceptions или экономить на них. Если есть исключительная ситуация — однозначно бросать эксепшен. А Stream.Null возвращать (или передавать, например), только если это логически оправданно, а не как сигнал об ошибке; и соображения производительности здесь не стоит вообще учитывать.Как пример юзкейса — метод, который делает что-то и еще что-то пишет в поток (журнала, например). Если мы хотим это проигнорировать, то передаем Stream.Null, и все.
Справедливое негодование общественности вызвала идея возврата Stream.Null, а не передачи его в метод.
Фу как не красиво. Апочему не тётушка програмиста? К чему этьо замечание вообще добавлено? Что означает и как его надо понимать? Как к нему относиться? ИМХО, это из разряда "что бы ни сказать, лишь бы сказать" 
нет, серьёздно, ты какую реакцию ожидаешь на эти слова 
