On 13 June 2012 20:25, Stéphane Ducasse <Stephane.Ducasse@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 <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