thanks for this discussion it is interesting. I like small api fully implemented vs large and bogus ones
Stef On Nov 13, 2013, at 6:47 PM, Nicolas Cellier <nicolas.cellier.aka.n...@gmail.com> wrote: > > ---------- Forwarded message ---------- > From: Nicolas Cellier <nicolas.cellier.aka.n...@gmail.com> > Date: 2013/11/13 > Subject: Re: [Pharo-dev] In-memory FileSystem write streams not being > polymorphic > > The long answer is simple: the more responsibility you put in Stream, the > more complexity you get. > The first complexity that I'm speaking of is non-uniformity and random > implementation (or un-implementation) of a set of features. > I mean some streams in the huge hierarchy implement only half of the > contract, but hey, what was the contract exactly? > Ah, yes, there were no contract, just hacks left here and there randomly and > concurrently in a big hierarchy. > I add a new subclass, but don't implement all the features, there are too > many of them, and I don't know them all.. > I add a new feature, but don't implement it in all the classes, there are too > many of them, and I don't know them all. > This procedure invariably ends up with a blob of un-maintanable code, were > two stream would not even agree on upToEnd behavior - I think you remember it > :) > > If the goal is to replicate all the accumulated responsibilities of Squeak > Streams, but with a clarified contract, I think this is a dead end: too much > cruft to support, too many features, too many undefined or not well defined > behaviors to be clarified. > > Xtreams takes the opposite path: concentrate on constructing a common, simple > and uniform API, concerning streams, just basic stream methods. > Some specialized streams then implement some specialized behavior, and you > can compose them (by wrapping) when you need the specific API. > This way, you ain't got to implement/maintain feature A into a few dozen of > classes. > And your brand new SpecialFeatureBStream only has to implement a few well > known behaviours and your Special Feature B. > > The short answer is even more simple : a stream does not have a name, like a > collection does not have a name, because we ain't gonna need it. > If we really need a name, then we'll create a XTNamedReadStream and a > XTNamedWriteStream responding to #name, but I doubt we'll do. > > > 2013/11/13 Chris Muller <ma.chri...@gmail.com> > On Wed, Nov 13, 2013 at 9:58 AM, Nicolas Cellier > <nicolas.cellier.aka.n...@gmail.com> 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. > > > 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? > > IMHO working around that, passing extra objects around, sounds more stressful > than letting a stream on a _file_ know its filename.. > > 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? > > > > > > > > 2013/11/13 Chris Muller <asquea...@gmail.com> > On Tue, Nov 12, 2013 at 7:31 AM, Nicolas Cellier > <nicolas.cellier.aka.n...@gmail.com> 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? > > > > >
