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? >>> >> >
