Yes, a Wrapper would provide the legacy API. And yes, the name of a stream should better not be part of the API. Most stream don't have a name, and adding such API adds all sort of un-needed complexity. It's an internal detail that can eventually help for reporting error if accessible, but nothing more.
If it really need it, the application certainly can retrieve the name from a higher level object (a FIleReference, FileDirectory or whatever). 2013/11/13 Chris Muller <asquea...@gmail.com> > On Tue, Nov 12, 2013 at 7:31 AM, 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) > > 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? > >
