2012/6/14 Henrik Sperre Johansen <henrik.s.johan...@veloxit.no>: > On 14.06.2012 08:43, Igor Stasenko wrote: >> >> On 14 June 2012 08:33, Stéphane Ducasse<stephane.duca...@inria.fr> wrote: >>> >>> Tx >>> >>> now there is a difference between adjustments and fully new API and I >>> would have preferred adjustments. >>> >>> Stef >> >> IMO, Xtreams design is simply superior. > > +100. > I gave up on trying to mold the current Streams into something a bit more > reasonable and still be backwards compatible quite some time ago. > > That other thread about Converters? > Totally related. For example, you can't do what Sven did in the Zn > converters without breaking backwards compatability. Nor could you do it > reasonably fast in the general case, since fast string -> bytearray > streaming works for some streams, but not for others. (which, I guess, is > one reason why the legacy converters do string -> string.) > > IMHO, Xtreams would be a perfect fit to go with the new FileSystem as well. > (using compositing on top of a "dumb" terminal) >
Quite sure that it is highly ranked in Colin's plans. >> But i agree, we cannot throw existing streams out.. too much things >> tied to them, and rely >> on using stream protocols. :( > > Well, one*could* try to introduce something akin to the Zn HTTPClient > compatability protocol, strictly speaking what you can do with Xtreams is a > superset of what Streams currently do. > The problem is all the moronic quirks of the current Streams, and clients > potentially relying on that behaviour. > > Cheers, > Henry > > >
