By the way,
OrderedCollection new writing
write: ({1. 2. 3.} as: OrderedCollection);
conclusion
2012/6/13 Nicolas Cellier <nicolas.cellier.aka.n...@gmail.com>:
> 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 <dionisi...@gmail.com>:
>> And why no Xtreams?
>>
>> 2012/6/13 <petton.nico...@gmail.com>
>>
>>> Guillermo Polito <guillermopol...@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 <le...@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 <camillobr...@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
>>>
>>
