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