Just forgot to add this reductio ad absurdum: I suggest Object ^'John Doe', this is a relatively current name, so it shouldn't hurt.
2013/11/13 Nicolas Cellier <[email protected]> > > ---------- Forwarded message ---------- > From: Nicolas Cellier <[email protected]> > 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 <[email protected]> > >> 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. >>> >>> >> 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 <[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? >>>> >>>> >>> >> > >
