LR[ ComVisibleAttribute(true) ]
public abstract class Stream : MarshalByRefObject , IDisposable

Похоже, именно поэтому.

mikronоткудого у тебя возникнет эксепшен? Может кто то всё-же будет делать проверки?

У тебя метод есть, загружающий данные из потока. Что тебе даст чтение CanRead? Скажет только, что о том, что поток не читабельный. А почему не скажет. Чтобы выяснить почему, надо всё таки попробовать выполнить чтение и надеяться на то, что в исключении будет больше информации.

Будет ещё прикольней, если CanRead бросит исключение )))
Или CanRead вернёт false, а сам поток при этом вполне читабельный.

Жопа короче.


mikronЗначит всё-таки твой интерфейс ничего не гарантирует. Значит нет в нём ползы. Исползуй базовый класс Stream.

Интерфейс это контракт. Контракт это гарантии. Гарантирует. Если нет, то всеми контрактами можно подтереться.

mikronОтвет на твой вопрос не однозначен, но в обшем случае я не буду делать никаких проверок.

А почему? Там ведь может быть стрим, который не умеет читать, а только писать.


mikronЭто только подчёркивает что нет смысла плодить интерфейсы IReadStream. Базового класса Stream kak это делает МС достаточно.

Я понял, твой единственный аргумент это авторитет Microsft. Раз MS так решила, значит это самый верный путь. Всё ясно.

mikronhVosttЧаще всего потоки используются только на чтение или только на запись, а клиентам теперь приходится лишний раз проверять Stream, умеет ли он то, что от него требуется (CanRead, CanWrite, CanSeek), вместо того, чтобы выяснить это ещё на стадии компиляции (IReadStream / IWriteStream / ISeekStream).

Надеёсь мы прояснили, что на этапе компиляции этого нелзя выяснит?

Не выдумывай. На этапе компиляции выясняется соответствие интерфейсов. Т.е. выполнение контрактов, которые гарантируют соответствующую реализацию. Если что-то не реализовано по контракту, это ошибка разработчика, он идёт и исправляет её. Или ошибка глубже, например, сетевая ошибка, ошибка файловой системы. Сам контракт гарантирует реализацию, а не правильную реализацию.

mikronhVostt,

Я устал, я умолкаю

Ну ок :)

ЕвгенийВ9 лет назад тоже делал WebDAV, не представляю, нафига там нужен свой Stream....

WebDAV представляет виртуальную файловую систему. В нашем случае, на деле ни файлов, ни каталогов не существует, они для каждого пользователя свои. Пользователи работают с файлами, открывая их и копируя, это реализовывается через сетевой интерфейс, который работает с потоками.

ЕвгенийВИ да, друг мой Хвост, умные люди читают из потока используя например BinaryReader.

А конструктор BinaryReader что по-твоему принимает? Тот же Stream. Который хрен ещё его знает, умеет читать или нет. Узнаешь потом.

ЕвгенийВЕсли проводник windows может выступать клиентом WebDAV, не значит, что WebDAV "представляет виртуальную файловую систему (с)".
WebDAV - расширение HTTP и может и используется (в microsoft exchange) например для доступа к почте.

Я вообще не понял к чему ты это сказал. У нас есть виртуальная файловая система, индивидуальная для каждого пользователя, мы предоставляем доступ к ней через WebDAV. Есть аналогичный доступ через веб интерфейс. При желании, можно замутить FTP интерфейс или ещё какой-нибудь.

ЕвгенийВЭто да, но он и сделает все проверки, которые лень делать простому программисту :)

То есть мало того, что я должен сделать отдельный класс, так как я не могу просто реализовать интерфейс читателя из потока, мне нужен отдельный класс. Я должен использовать ещё какой-то дополнительный класс, чтобы реализовать чтение из класса потока, который я сам же сделал. Не находишь, что это перебор?

Cat2А мне плевать. Я работаю в одиночку

Гыгыг