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... :/
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
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
