2012/6/13 St�phane Ducasse <Stephane.Ducasse@inria.fr>

I would have really prefer that Xtreams provide a compatible API.
Because changing API means also rewrite documentation�.

Nicolas else did you get Xtream working well in Pharo?
Because we will nearly killed all the old FileDirectory code. So stream would be good candidate to clean too.
Stef

> If it's about switching to a clean library maximizing the power of
> composition use Xtreams.
> If it's about maximizing compatibility, use Nile. The composition in
> Nile is done via Traits, this is interesting but spectrum is quite
> narrow. Nile also introduces lazy streams and filters, but this is
> less systematic than Xtreams, because the main goal was to replace
> legacy Stream, innovation being secondary.
>
> Of course, in the first case, you break a lot of clients because
> design decision is to change the whole API and force a rewrite.
> So you must have a long transition phase maintaining legacy Streams
>
> And in second case, you can eliminate the legacy streams more rapidly
> and just replace them with Nile, but you still carry some cruft,
> compatibility oblige...
>
> Not an easy choice, but you can guess my opinion ;)
>
> Nicolas
>
> 2012/6/13 Denis Kudriashov <dionisiydk@gmail.com>:
>> And why no Xtreams?
>>
>> 2012/6/13 <petton.nicolas@gmail.com>
>>
>>> Guillermo Polito <guillermopolito@gmail.com> writes:
>>>
>>>> Ok, just was expecting (very very deeply) not having to modify too
>>>> much in Glorp :). Anyway, I'll see what can I do in this front.
>>>>
>>>> Now Damien, if streaming is only intended for arrays and strings, I'd
>>>> expect the expression 'OrderedCollection new writeStream' to raise an
>>>> error... :/
>>>
>>> Indeed. Also, just for my information, why aren't we using Nile?
>>>
>>> Nico
>>>
>>>>
>>>> On Wed, Jun 13, 2012 at 5:29 PM, Levente Uzonyi <leves@elte.hu> wrote:
>>>>
>>>> � �On Wed, 13 Jun 2012, Guillermo Polito wrote:
>>>>
>>>> � � � �soo, what do I do? :D
>>>>
>>>>
>>>>
>>>> � �Streaming into an OrderedCollection is unnecessary, because
>>>> � �OrderedCollection is already a stream-like object. If I were
>>>> � �implementing Smalltalk now, I would probably add the stream
>>>> � �protocol to it (#nextPut:, #nextPutAll:, etc).
>>>> � �A simple fix to your problem is to replace the line
>>>>
>>>> � � � � � grownCollection := collection class new: newSize.
>>>>
>>>> � �with
>>>>
>>>> � � � � � grownCollection := collection class ofSize: newSize.
>>>>
>>>> � �in WriteStream >> #growTo: (note that I didn't check current Pharo
>>>> � �code, so this might be different there).
>>>>
>>>>
>>>> � �Levente
>>>>
>>>>
>>>>
>>>>
>>>> � � � �On 6/13/12, Camillo Bruni <camillobruni@gmail.com> wrote:
>>>>
>>>> � � � �yup I know that :D
>>>> � � � � � �And I provided a fix on e year ago, that got lost in a big
>>>> � � � � � �refactoring...
>>>> � � � � � �- I added an explicit #streamSpecies on the Collection
>>>> � � � � � �classes.
>>>> � � � � � �- By default it returns the same class
>>>> � � � � � �- on Set / OrderedCollection / Symbol it returns the
>>>> � � � � � �mutable types
>>>> � � � � � �(LinkedList as well I think)
>>>> � � � � � �- overwrote #streamContents: to convert from the
>>>> � � � � � �#streamSpecies type back to
>>>> � � � � � �the original class
>>>>
>>>>
>>>>
>>>> � � � � � �On 2012-06-13, at 14:56, Guillermo Polito wrote:
>>>>
>>>> � � � � � � � � � � � �Hi guys!
>>>>
>>>> � � � � � � � �I'm chasing a bug that appeared in glorp under pharo
>>>> � � � � � � � �1.4. �Now, the
>>>> � � � � � � � �bug is due to some behavior changed in
>>>> � � � � � � � �OrderedCollection I think. Look
>>>> � � � � � � � �at this piece of code:
>>>>
>>>>
>>>> � � � � � � � �oc := OrderedCollection new.
>>>> � � � � � � � �ws := oc writeStream.
>>>>
>>>> � � � � � � � �"this explodes"
>>>> � � � � � � � �ws nextPutAll: (OrderedCollection with: 1 with: 2
>>>> � � � � � � � �with: 3).
>>>>
>>>> � � � � � � � �"this works"
>>>> � � � � � � � �ws nextPutAll: {1.2.3}
>>>>
>>>>
>>>> � � � � � � � �And I'm puzzled, why should one work and the other not
>>>> � � � � � � � �from the pov of the
>>>> � � � � � � � �user?
>>>> � � � � � � � �And how should I replace that behavior if it's my bug?
>>>>
>>>> � � � � � � � �putting an asArray for each nextPutAll: does not look
>>>> � � � � � � � �good for me... :S
>>>>
>>>> � � � � � � � �Tx,
>>>> � � � � � � � �Guille
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Nicolas Petton
>>> http://nicolas-petton.fr
>>>
>>
>