On Tue, Nov 12, 2013 at 7:31 AM, Nicolas Cellier <[email protected]> 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)
By wrappers you mean the Xtreams are the innards doing the work and the wrappers providing the legacy API? This would be a great way to test Xtreams. > 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. Are you saying a FileStream knowing its #name or #filename is bad?
