2013/2/24 Bob Arning <arning315 at comcast.net>:
> Ugly is the only valid criticism of
>
> WriteStream on: ''
>
> in Squeak, which I thought was the issue originally. Using a non-empty
> literal is, of course, asking for trouble. And if some code is becoming
> arguments passed to it from the outside, I think the problem may well lie
> with the receiver rather than the sender.
>

Ah, OK, I missed the second post of Eliot.
Even if we don't become: the literal (our first luck being that
#become: is expensive), we modify it if ever it is not empty (our
second luck)...

Anyway, my aim was not this specific pattern AnyKindOfStream on: '',
or '' writeStream, I think there are about 50 such in the image.
This pattern was used before I changed the methods, and I have chosen
to not modify too much (I can reconsider if we want to).

My aim was rather to specifically eliminate excessive usage of ReadWriteStream.

A first glimpse at code indicates that we almost never need a ReadWriteStream.
25% of use cases are just using write methods + contents.
74% of use cases are just for a false good reason - optimization.
That is:
1) we write
2) we reset
3) we read
The optimization is about space: this avoids a copy and a new allocation.
Very nice, but for example we could achieve same level of optimization
by just replacing the reset send by a readStream send, which would
create a well delimited readStream on the target up to writeLimit.

1% of use case, I could not analyze easily, code being too much convoluted ;)

I also saw that some methods are only implemented in ReadWriteStream -
like fileOutChanges.
I understand why they ended here, for letting an HtmlFileStream
prepend a header and append a trailer...
But all this is brittle...
First, HtmlFileStream sounds weird, why not a HtmlStringStream? Ah
yes, we cannot compose Streams, just inheritate...
Second, using a low level abstraction - a Stream - and hacking it to
handle higher level structures - header, trailer, ... - is exactly the
kind of cleverness that makes our simple abstractions become complex
and convoluted.
I understand that this gave us an HTML output at very low cost at
client side (just change name of the stream), and apparently not so
high a cost at library side (adding a subclass and a few messages in
the hierarchy does not seem very expensive).
But the hidden cost when we cripple the Stream library with many of
these little brittle API and excessive responsibility, is that it
becomes very hard to change/extend the library. We then start adding
features to some restricted parts of hierarchy and end up with
something that is fragile, non uniform and freezes because no one can
modify without breaking something.

Xtreams showed how nice and simple could the Stream library be.
I'd like to de-convoluate a bit current code toward that direction.
Whether we use Xtreams or just simplify Stream, I don't care, but we
have to do something.

Nicolas

> Cheers,
> Bob
>
> On 2/24/13 1:25 AM, tim Rowledge wrote:
>
> On 23-02-2013, at 5:34 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> On Sat, Feb 23, 2013 at 4:08 PM, Bob Arning <arning315 at comcast.net> wrote:
>
> I tried it and did not see a problem. That is an empty string, isn't it?
>
> Yes, and you're getting away with it because the WriteStream
> implementation doesn't use become: to grow strings.  But back in the
> day it did and would have resulted in a non-zero string.
>
> If Eliot's explanation doesn't convince you, just consider how ugly an
> expression it is. Let's have "WriteStream onNewString". Much more readable.
> Clearly expressed intent.
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> "bOtHeR" said Pooh, mistaking the LSD tablet for aspirin
>
>
>
>
>
>
>
>