Tx
now there is a difference between adjustments and fully new API and I would
have preferred adjustments.
Stef
On Jun 14, 2012, at 12:11 AM, Frank Shearar wrote:
> On 13 June 2012 20:25, Stéphane Ducasse <stephane.duca...@inria.fr> wrote:
>> I would have really prefer that Xtreams provide a compatible API.
>> Because changing API means also rewrite documentation….
>
> If I recall correctly, Michael & Martin said that it was impossible to
> provide a compatible API because the ANSI Stream protocol was
> fundamentally broken in a few key ways. I forget the details though,
> sadly.
>
>> Nicolas else did you get Xtream working well in Pharo?
>
> It should work just fine. As I recall there wasn't much adjustment
> necessary for Squeak (but of course Nicolas would know better than
> anyone!).
>
> frank
>
>> 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 <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
>>>>>
>>>>
>>>
>>
>>
>
