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)
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
