Fwd: In-memory FileSystem write streams not being polymorphic
---------- Forwarded message ---------- From: Nicolas Cellier <nicolas.cellier.aka.nice@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.chris.m@gmail.com>
On Wed, Nov 13, 2013 at 9:58 AM, Nicolas Cellier < nicolas.cellier.aka.nice@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 <asqueaker@gmail.com>
On Tue, Nov 12, 2013 at 7:31 AM, Nicolas Cellier <nicolas.cellier.aka.nice@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?
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 <nicolas.cellier.aka.nice@gmail.com>
---------- Forwarded message ---------- From: Nicolas Cellier <nicolas.cellier.aka.nice@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.chris.m@gmail.com>
On Wed, Nov 13, 2013 at 9:58 AM, Nicolas Cellier < nicolas.cellier.aka.nice@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 <asqueaker@gmail.com>
On Tue, Nov 12, 2013 at 7:31 AM, Nicolas Cellier <nicolas.cellier.aka.nice@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?
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.nice@gmail.com> wrote:
---------- Forwarded message ---------- From: Nicolas Cellier <nicolas.cellier.aka.nice@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.chris.m@gmail.com> On Wed, Nov 13, 2013 at 9:58 AM, Nicolas Cellier <nicolas.cellier.aka.nice@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 <asqueaker@gmail.com> On Tue, Nov 12, 2013 at 7:31 AM, Nicolas Cellier <nicolas.cellier.aka.nice@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?
participants (2)
-
Nicolas Cellier -
Stéphane Ducasse