I don't disagree that Seek should be there; just not in it's current form. i.e. that it supports SeekOrigin.Begin/End, or re-uses SeekOrigin at all. I may have been too restrictive in suggesting Seek should only support an unsigned offset; but, most uses of a stream are unidirectional.
Whether or not Stream is in a "buffered" mode (you can use Stream-derived classes that write directly to the resource, aka unbuffered) should not impose locking. I would suggest that buffered IO should not support concurrent/thread-safe access--which would not be possible without the suggested "atomic" method addition. On Sat, 17 Dec 2005 16:50:33 +0100, Frans Bouma <[EMAIL PROTECTED]> wrote: >> I think the current Stream.Seek() is a pollution of a stream >> abstraction that has been kludged with the likes of CanSeek(). > > I disagree. Seek() is only weird in a forward only cursor style stream, thus a stream of bytes in which you can't go back >into. > > To me that's a 'stream'. What currently is implemented as Stream is an R/W buffer with a readpointer you can position where >you want. That of course will never be thread-safe unless the buffer is locked per call to write/read. > > FB > >=================================== >This list is hosted by DevelopMentor® http://www.develop.com > >View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
