Exactly, every specialized stream has its specialized API and/or specialized implementation. File streams don't even have a name, because they need not to. You can browse XTFileReadStream and XTFileWriteStream, you won't find such thing. The file has a name, the stream does not need any. Before adding anything to a stream, ask first, why am i going to need this?
2013/11/13 Frank Shearar <[email protected]> > On 13 November 2013 16:48, Chris Muller <[email protected]> wrote: > > I know nothing about Xtreams but, IMO, this obsession with sterility > > borders on mental illness. > > > > "All sort of un-needed complexity?" That's overstating it a bit, > > don't you think? > > > > So you must really feel stressed that ALL Object's, in fact, have a > > #name, huh? I admit this seems to push the limits but... > > > > what's the point of having any kind of different streams at all then? > > It's the _differences_ between them that makes composing them useful. > > Compression, encryption, filtering, sockets, files, circular, etc. > > You think you'll be able to do all that and get away with all of them > > having exactly the same API? > > They don't have the same API. And they shouldn't. And that's Nicolas' > whole point. A Stream does not have a name (nor should it - what's the > name of the compressed output of an audio stream from your > microphone?). A FileStream can extend this API, and that's fine. But > keep that out of the Stream API. > > So Nicolas is arguing that _difference_ should be reflected in the > API. File streams have names, but generic streams do not. > > As it happens, Xtreams takes a very disciplined approach to this. Some > streams have positions, and so you can go back. Some can't. This is > reflected in the API. This is good. > > > IMHO working around that, passing extra objects around, sounds more > > stressful than letting a stream on a _file_ know its filename.. > > Mu. Streams have no names. File streams have names. > > frank > > >> If it really need it, the application certainly can retrieve the name > from a higher level object (a FIleReference, FileDirectory or whatever). > > > > How does that solution allow uniformity in stream-using code? > > > > On Wed, Nov 13, 2013 at 9:58 AM, Nicolas Cellier > > <[email protected]> wrote: > >> Yes, a Wrapper would provide the legacy API. > >> > >> And yes, the name of a stream should better not be part of the API. > >> Most stream don't have a name, and adding such API adds all sort of > >> un-needed complexity. > >> It's an internal detail that can eventually help for reporting error if > >> accessible, but nothing more. > >> > >> If it really need it, the application certainly can retrieve the name > from a > >> higher level object (a FIleReference, FileDirectory or whatever). > >> > >> > >> 2013/11/13 Chris Muller <[email protected]> > >>> > >>> On Tue, Nov 12, 2013 at 7:31 AM, Nicolas Cellier > >>> <[email protected]> wrote: > >>> > It's just a matter of selecting a strategy. I've proposed two: > >>> > A) create a wrapper class for legacy Stream compatibility selectors > >>> > B) create extensions for Legacy Stream compatibility selectors > >>> > My preference goes to A) > >>> > >>> By wrappers you mean the Xtreams are the innards doing the work and > >>> the wrappers providing the legacy API? > >>> > >>> This would be a great way to test Xtreams. > >>> > >>> > The legacy support MUST be minimal (next nextPut: nextPutAll: peek > upTo: > >>> > ...), otherwise we will import all the cruft in Xtream and would go > back > >>> > to > >>> > our starting point... > >>> > Once the minimal support written (a few hours should be enough), we > >>> > should > >>> > gradually switch each every legacy Stream usage -> Xtream. > >>> > > >>> > An area which require more work is those Streams that have mixed > >>> > conventions > >>> > (one portion is interpreted as text, another as binary). > >>> > In theory that's easy, we just have two streams and they both wrap > on a > >>> > low > >>> > level binary stream, but that means we have to be very cautious with > >>> > buffers > >>> > and caches. > >>> > > >>> > Another area of work is usage of ugly selectors like name (we try to > >>> > access > >>> > the file name from the Stream API, arghh). Those usages are bad and > >>> > require > >>> > a rewrite. > >>> > >>> Are you saying a FileStream knowing its #name or #filename is bad? > >>> > >> > > > >
