BUG with OrderedCollection new writeStream ?

foo := OrderedCollection new writeStream.
foo nextPut: 42. "Say hello to the debugger"

...

Looks like http://bugs.squeak.org/view.php?id=2390

--
Damien Pollet, bonking head on desk

Les streams de Squeak sont incapables de traiter autre chose que des
String et des Array. C'est un des avantages de Nile.

2007/9/20, Damien Pollet <[hidden email]>:

--
Damien Cassou

Damien Pollet wrote:
> foo := OrderedCollection new writeStream.
> foo nextPut: 42. "Say hello to the debugger"

The #writeStream method is in practice usable only for
ArrayedCollections; Glorp for example uses an AddingWriteStream which is
little more than an adaptor (#contents returns the collection, #nextPut:
uses #addAll:).  I'm curious, how does Nile solve this problem?

Paolo

On 20/09/2007, Paolo Bonzini <[hidden email]> wrote:
> Damien Pollet wrote:
> > foo := OrderedCollection new writeStream.
> > foo nextPut: 42. "Say hello to the debugger"

In fact I think I have already been bitten by this :(

> The #writeStream method is in practice usable only for
> ArrayedCollections; Glorp for example uses an AddingWriteStream which is
> little more than an adaptor (#contents returns the collection, #nextPut:
> uses #addAll:).  I'm curious, how does Nile solve this problem?

I will definitely have a look at Nile, I was around when Damien worked
on it but I didn't get to actually use it.

--
Damien Pollet
type less, do more [ | ] http://typo.cdlm.fasmz.org

Paolo Bonzini a écrit :
VW solved the problem too, they use a message (collection growTo:
newSize) or something like that instead of (collection class new: newSize).

Nicolas

Le 20/09/07, Damien Cassou<[hidden email]> a écrit :
> Les streams de Squeak sont incapables de traiter autre chose que des
> String et des Array. C'est un des avantages de Nile.

I thought it was not a squeak-dev message, that's why I wrote in
French, sorry. Here is an English version:

Streams in Squeak have never been capable of dealing with classes
other than String and Array (and some subclasses). This is one of the
advantages of Nile which is able to work with any kind of
SequenceableCollection. It does so by using the Hollywood principle.
The stream asks the collection to grow and to write elements in
itself. I also implemented
OrderedCollection>>replaceFrom:to:with:startingAt:.

Bye

--
Damien Cassou

nicolas cellier wrote:
I've wondered though if it's necessary.  The adapter solution is better
in my humble opinion, because it is stupid that the stream imposes a
growing policy to a growing collection, and because an "adding stream"
would not need a final copy when calling #contents.

Paolo

Paolo Bonzini wrote:
>> VW solved the problem too, they use a message (collection growTo:
>> newSize) or something like that instead of (collection class new:
>> newSize).
>
> I've wondered though if it's necessary.  The adapter solution is better
> in my humble opinion, because it is stupid that the stream imposes a
> growing policy to a growing collection, and because an "adding stream"
> would not need a final copy when calling #contents.

True, however, the adapter solution makes it very difficult to create
streams that work on both sequenceable and arrayed collection. For
example, is GZipWriteStream a subclass of WriteStream or
AddingWriteStream? Do we need two classes, one for sequenceable and one
for arrayed collections? Does any new stream require an extra method in
sequenceable/arrayed collection (so that clients don't have to know
about what exactly they are dealing with)? All in all, I find the VW
solution of having a single polymorphic way that streams can use to
access both arrayed and sequenceable collections vastly preferable.

Cheers,
   - Andreas

>> I've wondered though if it's necessary.  The adapter solution is
>> better in my humble opinion, because it is stupid that the stream
>> imposes a growing policy to a growing collection, and because an
>> "adding stream" would not need a final copy when calling #contents.
>
> True, however, the adapter solution makes it very difficult to create
> streams that work on both sequenceable and arrayed collection. For
> example, is GZipWriteStream a subclass of WriteStream or
> AddingWriteStream?

Neither, it's a decorator :-)

> Do we need two classes, one for sequenceable and one for arrayed collections?

Yes, but a single constructor method #writeStream that picks the right
one.  So, you trade...

> a single polymorphic way that streams can use to
> access both arrayed and sequenceable collections vastly preferable.


... with a single polymorphic way to create the stream.

Paolo

Paolo Bonzini wrote:
Assuming you represent every new write stream as a decorator (I was only
giving an example).

Plus having to have all new write streams be decorators. It's doable but
doesn't strike me as superior to adding a single method in two classes.

Cheers,
   - Andreas

>> Neither, it's a decorator :-)
>
> Assuming you represent every new write stream as a decorator (I was only
> giving an example).

Understood, hence the smiley.

>> ... with a single polymorphic way to create the stream.
>
> Plus having to have all new write streams be decorators. It's doable but
> doesn't strike me as superior to adding a single method in two classes.

True, but that's a very good thing to do anyway.  Streams are very apt
to being written as decorators, and if you didn't use a decorator, the
same problem you have with WriteStream/AddingWriteStream would be
present with WriteStream/FileStream.

Paolo