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 >>>>> >>>> >>> >> >> >