And of course, I forgot all the usages of ReadWriteStream. I started rewriting some usage in Squeak, and good news, 95% of usage is unecessary, a WriteStream is sufficient.
2013/11/12 Nicolas Cellier <nicolas.cellier.aka.n...@gmail.com> > It's just a matter of selecting a strategy. I've proposed two: > A) create a wrapper class for legacy Stream compatibility selectors > B) create extensions for Legacy Stream compatibility selectors > My preference goes to A) > > The legacy support MUST be minimal (next nextPut: nextPutAll: peek upTo: > ...), otherwise we will import all the cruft in Xtream and would go back to > our starting point... > Once the minimal support written (a few hours should be enough), we should > gradually switch each every legacy Stream usage -> Xtream. > > An area which require more work is those Streams that have mixed > conventions (one portion is interpreted as text, another as binary). > In theory that's easy, we just have two streams and they both wrap on a > low level binary stream, but that means we have to be very cautious with > buffers and caches. > > Another area of work is usage of ugly selectors like name (we try to > access the file name from the Stream API, arghh). Those usages are bad and > require a rewrite. > > > 2013/11/12 Stéphane Ducasse <stephane.duca...@inria.fr> > >> >> >> or of course, you start looking at porting XStreams to pharo ;), which on >> the long run will >> solve many more problems. The current situation is not that satisfactory >> >> >> having experience with it and thinking about a plan for the beginning of >> 40 would be great. >> I know that nicolas ported XTream to pharo/squeak. Now understanding how >> integrate it would be nice. >> Stef >> >> >
