On Nov 12, 2013, at 2:31 PM, Nicolas Cellier <nicolas.cellier.aka.n...@gmail.com> wrote:
> 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) if I understand correctly I prefer A too. Because like that we can decide to even throw away later the wrapper and a wrapper is like a clear API. > 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 > >
